Связаться с намиПодключиться

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

Статья создана
Улучшена
Обновлена 7 ноября 2024 г.

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

Общее

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

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

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

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

Примечание

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

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

    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

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

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

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

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска дисков ВМ, которые не имеют 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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yandex Object Storage

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

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

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

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

  1. Если запрос прошел проверку IAM, к нему применяется проверка политики доступа.

  2. Проверка правил политики доступа происходит в следующем порядке:

    1. Если запрос подошел хотя бы под одно из правил Deny, то доступ будет запрещён.
    2. Если запрос подошел хотя бы под одно из правил Allow, то доступ будет разрешён.
    3. Если запрос не подошел ни под одно из правил, то доступ будет запрещён.

  3. Если запрос не прошёл проверку IAM или политики доступа, то применяется проверка доступа через ACL объекта.

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

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

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

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

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

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

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

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

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

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

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

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

Примеры Bucket Policy:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройте CORS.

3.11 Для получения временных ключей доступа к 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.12 Для единичных случаев доступа к отдельным объектам в непубличных бакетах Object Storage генерируются подписанные URL

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

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

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

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

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

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

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

Managed Services for Databases

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

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

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

  1. Выполните команду для поиска 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

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

  1. Выполните команду для поиска 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

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

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

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

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

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

    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. Если выдается пустая строка, рекомендация выполняется. Если нет, перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

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

    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. Если выдается пустая строка, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Найдите кластеры управляемых БД с включённым доступом из 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

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

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

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

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

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

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

    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.web_sql)' | jq -r '.id' 
done;
done;
done

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

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

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

Cloud Functions и Yandex API Gateway

3.18 Публичные облачные функции применяются только в исключительных случаях

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

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

  1. Выполните команду для поиска прав доступа allUsers, на уровне Cloud Functions во всех каталогах:

    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 FUN in $(yc serverless function list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc serverless function list-access-bindings --id $FUN --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $FUN
done;
done;
done

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

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

Отключите публичный доступ.

3.19 Учтены атаки по побочным каналам в Cloud Functions

Хосты и гипервизоры, на которых выполняются Cloud Functions, содержат все необходимые обновления для защиты от атак по побочным каналам процессора (side-channelattacks). Однако следует иметь в виду, что функции различных клиентов не изолированы по ядрам и формально существует поверхность атаки со стороны функции одного пользователя на функцию другого пользователя. Специалисты по ИБ Yandex Cloud считают сценарий атаки по побочным каналам в контексте функций маловероятным, однако следует учитывать данный риск, в частности, при построении модели угроз и анализа рисков для инфраструктуры PCI DSS.

Убедитесь, что наиболее критичные системы не используют Cloud Functions либо это учтено в модели угроз.

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

Сервис Cloud Functions не гарантирует синхронизацию времени перед выполнением или в процессе выполнения запросов функциями. Чтобы получить лог выполнения функции с точными метками времени на стороне Cloud Functions, следует выводить лог в stdout. Также клиент может самостоятельно принимать логи выполнения функции и помечать их меткой времени на принимающей стороне, взятой из источника времени, синхронизированного с Yandex Cloud. Подробнее о синхронизации времени см. в разделе Настройка синхронизации часов с помощью NTP документации Compute Cloud.

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

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

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

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

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

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

  1. Выполните команду для поиска всех облачных функций, для которых не заданы настройки сети в 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

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

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

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

Managed Service for YDB

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

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

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

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

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

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

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

    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. Если выдается пустая строка, то рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

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

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

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

Yandex Container Registry

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

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска 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 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

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

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

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

Yandex Container Solution

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

  2. Выполните команду для поиска 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

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

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

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

3.28 Срок действия сертификата 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 дней.

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

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

  1. Посмотрите доступные вам организации и зафиксируйте необходимый ID:

    yc organization-manager organization list

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

    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

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

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

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

Yandex Managed Service for GitLab

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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