3. Безопасная конфигурация виртуальной среды
В данном разделе представлены рекомендации клиентам по настройкам безопасности в облачных сервисах Yandex Cloud, а также использованию дополнительных средств защиты данных в виртуальной среде.
Общее
3.1 Использование серийной консоли контролируется либо отсутствует
На виртуальных машинах доступ к серийной консоли по умолчанию отключен. Риски использования серийной консоли перечислены в разделе Начало работы с серийной консолью документации Yandex Compute Cloud.
При работе с серийной консолью:
- Убедитесь, что критичные данные не попадают в вывод серийной консоли.
- При включенном доступе к серийной консоли по SSH убедитесь, что работа с учётными данными и пароль для локального входа в операционную систему соответствуют стандартам регуляторов. Например, в инфраструктуре для хранения данных платежных карт пароль должен соответствовать требованиям стандарта PCI DSS: содержать как буквы, так и цифры, иметь длину не менее 7 символов и меняться не реже чем каждые 90 дней.
Примечание
Согласно стандарту PCI DSS, доступ к виртуальной машине через серийную консоль считается «неконсольным» (non-console), и Yandex Cloud применяет для него шифрование TLS.
Не рекомендуется использовать доступ к серийной консоли без крайней необходимости.
- В консоли управления выберите каталог, ВМ которого хотите проверить.
- В списке сервисов выберите 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.2 Используется эталонный образ для развёртывания ВМ
При развёртывании виртуальных машин рекомендуется:
- Подготовить образ виртуальной машины, настройки системы в котором соответствуют вашей политике информационной безопасности. Создать образ можно с помощью Packer, см. раздел Начало работы с Packer.
- Использовать этот образ для создания виртуальной машины или Концепции Instance Groups.
- В информации о виртуальной машине убедиться, что для создания диска использовался именно этот образ.
- В консоли управления выберите каталог, ВМ которого хотите проверить.
- В списке сервисов выберите 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.3 Инструмент 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
- Пример: сканирование tf-файлов с помощью Checkov
. - Пример: хранение состояния Terraform в Object Storage
.
Проведите точечный сбор данных об использовании лучших практик по безопасности 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).
Подробнее
Yandex Object Storage
3.6 Отсутствует публичный доступ к бакету Object Storage
Рекомендуется назначать минимальные роли на бакет с помощью IAM и дополнять или детализировать их с помощью BucketPolicy (например, для ограничения доступа к бакету по IP-адресам, выдачи гранулярных прав на объекты и т.д.).
Проверка доступа к ресурсам Object Storage происходит на трёх уровнях:
- проверки сервиса IAM;
- политики доступа (bucketpolicy);
- списки управления доступом (ACL).
Порядок проверки:
-
Если запрос прошел проверку IAM, к нему применяется проверка политики доступа.
-
Проверка правил политики доступа происходит в следующем порядке:
- Если запрос подошел хотя бы под одно из правил Deny, то доступ будет запрещён.
- Если запрос подошел хотя бы под одно из правил Allow, то доступ будет разрешён.
- Если запрос не подошел ни под одно из правил, то доступ будет запрещён.
-
Если запрос не прошёл проверку IAM или политики доступа, то применяется проверка доступа через ACL объекта.
В сервисе IAM бакет наследует такие же права доступа, как у каталога и облака, в котором он находится. Подробнее об этом в разделе Наследование прав доступа на бакет системными группами Yandex Cloud. Поэтому рекомендуется выдавать только минимально необходимые роли на определенные бакеты или объекты сервиса Object Storage.
Политики доступа используются для дополнительной защиты данных, например, для ограничения доступа к бакету по IP-адресам, выдачи гранулярных прав на объекты и т. д.
ACL позволяет предоставить доступ к объекту в обход проверок IAM и политик доступа. Рекомендуем установить строгие ACL на бакеты.
Пример безопасной конфигурации Object Storage: Terraform
- В консоли управления выберите облако или каталог, бакеты которого вы хотите проверить.
- В списке сервисов выберите Object Storage.
- Нажмите на три точки напротив каждого бакета и проверьте ACL бакета на наличие allUsers и allAuthenticatedUsers.
- Зайдите внутрь бакета и проверьте ACL на каждый объект бакета на наличие allUsers и allAuthenticatedUsers.
- Проверьте, что в разделе Доступ на чтение объектов включен параметр Публичный. В противном случае перейдите к п. «Инструкции и решения по выполнению».
-
Настройте awscli на работу с облаком.
-
Выполните команду для 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 используется как минимум одна политика.
- В консоли управления выберите облако или каталог, политики доступа которых вы хотите проверить.
- В списке сервисов выберите Object Storage.
- Перейдите в раздел Политика доступа.
- Убедитесь, что как минимум одна политика включена. В противном случае перейдите к п. «Инструкции и решения по выполнению».
-
Настройте awscli на работу с облаком.
-
Выполните команду для 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 устанавливает, что аудитные логи должны храниться не менее одного года, и как минимум три месяца должны быть доступны онлайн.
- В консоли управления выберите облако или каталог, бакеты которых вы хотите проверить.
- В списке сервисов выберите 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.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.
- В консоли управления выберите облако или каталог, бакеты которых вы хотите проверить.
- В списке сервисов выберите Object Storage.
- Откройте настройки всех бакетов.
- Перейдите во вкладку CORS — конфигурация должна быть настроена. В противном случае перейдите к п. «Инструкции и решения по выполнению».
Инструкции и решения по выполнению:
Настройте CORS.
Managed Services for Databases
3.11 На управляемых базах данных назначена Группа безопасности
Рекомендуется запретить доступ из интернета к базам данных, которые содержат критичные данные, в частности данные PCI DSS или персональные данные. Настройте группы безопасности, чтобы разрешить подключение к СУБД только с определенных IP-адресов, см. инструкцию в разделе Создать группу безопасности. Указать группу безопасности можно в настройках кластера или при его создании, в блоке сетевых настроек.
- В консоли управления выберите облако или каталог, в которых вы хотите проверить базы данных.
- В списке сервисов выберите сервис(ы), где находятся управляемые базы данных.
- В настройках объектов найдите параметр Группа безопасности и убедитесь, что назначена хотя бы одна группа безопасности.
- Если в параметрах каждого объекта указана хотя бы одна группа безопасности, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».
-
Выполните команду для поиска 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.12 На управляемых базах данных не назначен публичный IP-адрес
Назначение публичного IP-адреса на управляемую базу данных повышает риски ИБ. Рекомендуется не назначать внешний 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.13 Включена настройка защиты от удаления (deletetion protection)
В управляемых базах данных в Yandex 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 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.14 Выключена настройка доступа из DataLens без необходимости
Не следует без необходимости включать доступ к базам данных c критичными данными из консоли управления, DataLens и других сервисов. Доступ из DataLens может потребоваться для анализа и визуализации данных. Эти доступы осуществляются через служебную сеть Yandex Cloud, с аутентификацией и использованием шифрования TLS. Включить и отключить доступы из DataLens или других сервисов можно в настройках кластера или при его создании, в блоке дополнительных настроек.
- В консоли управления выберите облако или каталог, в которых вы хотите проверить базы данных.
- В списке сервисов выберите сервис(ы), где находятся управляемые базы данных.
- В настройках объектов перейдите во вкладку Дополнительные настройки.
- Если в параметрах каждого объекта отключена опция Доступ из 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.15 На управляемых БД выключен доступ из консоли управления
Доступ к БД из консоли управления может потребоваться для отправки SQL-запросов в БД и визуализации структуры данных.
Рекомендуется включать такой доступ только в случае необходимости, т.к. он увеличивает риски ИБ. В штатном режиме используйте стандартное подключение к БД под пользователем БД.
- В консоли управления выберите облако или каталог, в которых вы хотите проверить базы данных.
- В списке сервисов выберите сервис(ы), где находятся управляемые БД.
- В настройках объектов перейдите во вкладку Дополнительные настройки.
- Если в параметрах каждого объекта отключена опция Доступ из консоли управления, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».
-
Посмотрите доступные вам организации и зафиксируйте необходимый ID:
yc organization-manager organization list
-
Выполните команду для поиска кластеров управляемых БД 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
-
Если выдается пустая строка, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».
Инструкции и решения по выполнению:
- В консоли управления выберите облако или каталог, в которых вы хотите выключить доступ из консоли.
- В списке сервисов выберите сервис(ы), где находятся управляемые базы данных.
- В настройках объектов перейдите во вкладку Дополнительные настройки.
- В параметрах объекта выключите опцию Доступ из консоли.
Cloud Functions и Yandex API Gateway
3.16 Публичные облачные функции применяются только в исключительных случаях
Во всех случаях, когда явно не требуется использование публичных функций, рекомендуется использовать приватные функции. Подробнее о настройке доступа к функциям см. в разделе Управление правами доступа к функции. Рекомендуется использовать приватные функции и назначать права на вызов функции конкретным пользователям облака.
- В консоли управления выберите облако или каталог, в которых вы хотите проверить функции.
- В списке сервисов выберите Cloud Functions.
- Откройте все функции.
- В настройках функций перейдите во вкладку Обзор.
- Если в параметрах каждого объекта опция Публичная функция отключена, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».
-
Выполните команду для поиска прав доступа
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
-
Если в каждом указанном ресурсе отсутствуют субъекты
allUsers
иallAuthenticatedUsers
, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».
Инструкции и решения по выполнению:
Отключите публичный доступ.
3.17 Учтены атаки по побочным каналам в Cloud Functions
Хосты и гипервизоры, на которых выполняются Cloud Functions, содержат все необходимые обновления для защиты от атак по побочным каналам процессора (side-channelattacks). Однако следует иметь в виду, что функции различных клиентов не изолированы по ядрам и формально существует поверхность атаки со стороны функции одного пользователя на функцию другого пользователя. Специалисты по ИБ Yandex Cloud считают сценарий атаки по побочным каналам в контексте функций маловероятным, однако следует учитывать данный риск, в частности, при построении модели угроз и анализа рисков для инфраструктуры PCI DSS.
Убедитесь, что наиболее критичные системы не используют Cloud Functions либо это учтено в модели угроз.
3.18 Учтены особенности синхронизации времени в Cloud Functions
Сервис Cloud Functions не гарантирует синхронизацию времени перед выполнением или в процессе выполнения запросов функциями. Чтобы получить лог выполнения функции с точными метками времени на стороне Cloud Functions, следует выводить лог в stdout. Также клиент может самостоятельно принимать логи выполнения функции и помечать их меткой времени на принимающей стороне, взятой из источника времени, синхронизированного с Yandex Cloud. Подробнее о синхронизации времени см. в разделе Настройка синхронизации часов с помощью NTP документации Compute Cloud.
3.19 Учтены особенности управления заголовками в Cloud Functions
Если функция вызывается для обработки HTTP-запроса, то возвращаемый результат должен представлять собой JSON-документ, содержащий код ответа HTTP, заголовки ответа и содержимое ответа. Cloud Functions автоматически обработает этот JSON, и пользователь получит данные в виде стандартного HTTP-ответа. Клиенту необходимо самостоятельно управлять заголовками ответа в соответствии с требованиями регуляторов и модели угроз. Инструкцию по обработке HTTP-запроса см. в статье Вызов функции в Cloud Functions документации Cloud Functions.
3.20 Serverless Containers/Cloud Functions использует внутреннюю сеть VPC
По умолчанию функция запускается в изолированной IPv4-сети с включённым NAT-шлюзом. Поэтому из функции доступны только публичные IPv4-адреса.
Если необходимо, в настройках функции можно указать облачную сеть. Тогда функция будет:
- Исполняться в указанной облачной сети.
- Иметь доступ не только в интернет, но и к пользовательским ресурсам, которые находятся в указанной сети, например, базам данных, виртуальным машинам и т.п.
- Иметь IP-адрес в диапазоне
198.19.0.0/16
при доступе к пользовательским ресурсам.
- В консоли управления выберите облако или каталог, в которых вы хотите проверить функции.
- В списке сервисов выберите 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.
Managed Service for YDB
3.21 Учтены рекомендации по работе с конфиденциальными данными в YDB
Запрещается в качестве названий базы данных, таблиц, столбцов, директорий и т.д. использовать конфиденциальные данные. Запрещается отправлять критичные данные (например данные платежных карт) в Managed Service for YDB (как Dedicated, так и Serverless) в открытом виде. Перед отправкой данных их необходимо шифровать на уровне приложения, для чего можно воспользоваться сервисом KMS или любым другим способом, соответствующим стандарту регуляторов. Если срок хранения данных известен заранее, рекомендуется настроить функцию Time To Live
3.22 Учтены рекомендации по защите от sql-инъекций YDB
При работе с базой данных для защиты от SQL-инъекций необходимо использовать параметризованные подготовленные запросы
3.23 Публичный доступ отсутствует для YDB
При работе с базой данных в режиме Dedicated рекомендуется использовать её внутри VPC и не открывать к ней доступ из интернета. В режиме Serverless база данных является доступной из интернета, что необходимо учитывать, в частности, при моделировании угроз при построении инфраструктуры. Подробнее о режимах работы см. в разделе Режимы работы Serverless и Dedicated документации Managed Service for YDB.
При настройке доступа к БД следует использовать принцип минимальных привилегий.
- В консоли управления выберите облако или каталог, в которых вы хотите проверить базу данных.
- В списке сервисов выберите 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.24 Учтены рекомендации по резервному копированию YDB
При использовании механизма создания резервных копий по требованию, необходимо убедиться, что данные резервной копии должным образом защищены.
При самостоятельном создании резервных копий в сервисе Object Storage необходимо следовать рекомендациям подраздела Object Storage выше — например, использовать встроенные возможности шифрования бакетов.
Yandex Container Registry
3.25 Настроен ACL по IP адресам для Yandex Container Registry
Доступ к вашему Container Registry рекомендуется ограничить до конкретных IP-адресов.
- В консоли управления выберите облако или каталог, в которых необходимо проверить реестр.
- В списке сервисов выберите Container Registry.
- В настройках конкретного реестра перейдите во вкладку Доступ для IP-адресов.
- Если в параметрах указаны конкретные адреса для доступа, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».
-
Посмотрите доступные вам организации и зафиксируйте необходимый 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 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
-
Если перед каждым ID registry выдаётся PULL/PUSH, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».
Инструкции и решения по выполнению:
Задайте конкретные адреса для доступа к реестрам.
Yandex Container Solution
Не рекомендуется использовать привилегированные контейнеры для запуска нагрузок, обрабатывающих недоверенный пользовательский ввод. Привилегированные контейнеры следует использовать для администрирования виртуальной машины или других контейнеров.
- В консоли управления выберите облако или каталог, в которых необходимо проверить ВМ.
- В списке сервисов выберите 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.26 Срок действия сертификата 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 дней
Рекомендуется заблаговременно обновлять сертификат, если вы не используете автоматическое обновление.
- В консоли управления выберите облако или каталог, в которых необходимо проверить ВМ.
- В списке сервисов выберите 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.27 Рекомендации по настройке безопасности инстанса GitLab выполняются
Рекомендации представлены здесь.
Необходимо проверить вручную.
3.28 Используется антивирусная защита
Необходимо обеспечить защиту от вредоносного ПО в своей зоне ответственности. Возможно применение различных решений от наших партнеров в Yandex Cloud Marketplace.
Образы антивирусных решений доступны в Yandex Cloud Marketplace. Типы лицензий и другая необходимая информация доступны в описаниях продуктов.
Необходимо проконтролировать наличие антивирусных решений в критичных системах.
Инструкции и решения по выполнению:
Установите антивирусное решение в соответствии с инструкциями поставщика.
3.29 Используются рекомендации по безопасности Yandex Managed Service for Kubernetes
Вы можете ознакомиться с рекомендациями в разделе Безопасность Kubernetes.