Стандарт по защите облачной инфраструктуры Yandex Cloud 1.2

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

Yandex Cloud

Улучшена

Обновлена 18 ноября 2024 г.

Введение
1. Аутентификация и управление доступом
2. Сетевая безопасность
3. Безопасная конфигурация виртуальной среды
4. Шифрование данных и управление ключами
5. Сбор, мониторинг и анализ аудитных логов
6. Резервное копирование
7. Физическая безопасность
8. Защита приложений
- Рекомендации по защите приложения от роботной активности
- Рекомендации по построению безопасного пайплайна
9. Безопасность Kubernetes

Введение

Этот документ содержит рекомендации по техническим мерам защиты и помогает выбрать меры обеспечения информационной безопасности (ИБ) при развёртывании информационных систем на облачной платформе Yandex Cloud.
Рекомендации и меры обеспечения безопасности в стандарте сопровождаются ссылками на Инструкции и решения по настройке безопасных конфигураций ресурсов с помощью штатных средств защиты информации и дополнительных средств защиты, доступных пользователям Yandex Cloud.
Также стандарт описывает способы и средства проверки выполнения рекомендаций, в том числе:

с помощью интерфейса консоли управления;
с помощью интерфейса командной строки Yandex Cloud CLI;
вручную.

Область применения

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

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

Структура стандарта

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

Аутентификация и управление доступом.
Сетевая безопасность.
Безопасная конфигурация виртуальной среды.
Шифрование данных и управление ключами.
Сбор, мониторинг и анализ аудитных логов.
Резервное копирование.
Физическая безопасность.
Защита приложений.
Безопасность Kubernetes.

Требования и подготовка

Для проверок убедитесь, что

установлен и настроен YC CLI по инструкции;
вы вошли в консоль управления;
установлена утилита jq.

Вы можете автоматизировать аудит выполнения всех рекомендаций с помощью доступных решений наших партнёров:

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

Ограничение ответственности

В Yandex Cloud применяется концепция разделения ответственности. Граница разделения ответственности за обеспечение безопасности зависит от сервисов, которые используются системой в облаке, от модели использования этих сервисов (IaaS — инфраструктура как услуга, PaaS — платформа как услуга, SaaS — программное обеспечение как услуга) и имеющихся у облачного провайдера защитных механизмов и политик.

Термины и сокращения

В настоящем документе используются термины и определения, введенные стандартом ISO/IEC 27000:2018 и ISO/IEC 29100:2011, а также термины, используемые в глоссарии Yandex Cloud.

1. Аутентификация и управление доступом

В Yandex Cloud управление идентификацией, аутентификацией и контролем доступа выполняется сервисами Yandex Identity and Access Management (IAM) и Yandex Cloud Organization.

Платформа работает с тремя категориями пользователей:

аккаунты на Яндексе — учетные записи в системе Яндекс ID;
федеративные аккаунты — учетные записи в корпоративной SAML-совместимой федерации удостоверений, например Active Directory;
сервисные аккаунты — учетные записи, от имени которых программы могут управлять ресурсами.

Аккаунты Яндекс ID и федеративные аккаунты аутентифицируются в собственных системах. Yandex Cloud не имеет доступа к паролям этих пользователей и аутентифицирует только сервисные аккаунты с помощью сервиса IAM.

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

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

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

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

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

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

Совет

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

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите во вкладку Все сервисы → Yandex Cloud Organization → Федерации.
Если в списке есть хотя бы одна настроенная федерация удостоверений, то рекомендация выполнена. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

Посмотрите информацию о настроенных федерациях:

yc organization-manager federation saml list \
  --organization-id=<ID организации>

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

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

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

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

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

1.2 Учетные записи Яндекс ID используются только в исключительных случаях

Наиболее правильный с точки зрения безопасности подход к управлению учетными записями — это использование федерации удостоверений (подробнее в рекомендации № 1.1). В связи с этим необходимо стремиться к тому, чтобы в списке пользователей вашей организации находились только федеративные пользователи (пользователи c атрибутом FEDERATION ID) и минимум учетных записей с Яндекс ID. Список допустимых исключений:

Учетная запись с правами billing.accounts.owner (технически на текущий момент данную роль может иметь только учетная запись Яндекс ID).
Учетная запись с правами organization-manager.organizations.owner и resource-manager.clouds.owner, если вы используете ее только для аварийного применения, например, когда сломалась настройка федерации. При необходимости можно удалить привилегированный паспортный аккаунт с ролью organization-manager.organizations.owner из организации.
Внешние учетные записи, например, контрагентов или подрядчиков, которые по каким-либо причинам вы не можете завести в вашей IdP.

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите во вкладку Все сервисы → Yandex Cloud Organization → Пользователи.
Если у всех учетных записей в колонке Федерация выставлено значение federation (кроме записей, указанных в списке допустимых исключений выше), то рекомендация выполняется. Если нет, перейдите к п. Инструкции и решения по выполнению.

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

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

yc organization-manager user list --organization-id=<ID организации> \
  --format=json | jq -r '.[] | select(.subject_claims.sub!="<ID учетной записи, которая входит в список валидных исключений>")' | jq -r 'select(.subject_claims.federation | not)'

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

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

Удалите из вашей организации все учетные записи с Яндекс ID, кроме случаев из списка допустимых исключений.

1.3 Только необходимые администраторы управляют членством в IAM-группах

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите во вкладку Все сервисы → Yandex Cloud Organization → Группы → Выберите нужную группу → Права доступа к группе.
Нажмите тумблер Наследуемые роли.
Если в списке отсутствуют учетные записи, которые не должны иметь прав управления членством в группе, то рекомендация выполнена. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

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

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

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

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите во вкладку Все сервисы → Yandex Cloud Organization → Пользователи.
Если у всех учетных записей в колонке Права доступа отсутствуют примитивные роли admin, editor и viewer, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.
Далее перейдите в общее меню облака (нажать на облако в исходном меню облака). Выберите вкладку Права доступа.
Если у всех учетных записей в колонке Роли отсутствуют примитивные роли admin, editor и viewer, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.
Далее перейдите в каждый каталог каждого облака и по аналогии перейдите во вкладку Права доступа.
Если у всех учетных записей в колонке роли отсутствуют примитивные роли admin, editor и viewer, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

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

export ORG_ID=<ID организации>
yc organization-manager organization list-access-bindings \
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'

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

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'
done

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

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

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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="viewer")'
done;
done

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

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

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

1.5 Облачные сущности с сервисными аккаунтами учтены и ограничены

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

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

При использовании сервисных аккаунтов:

Применяйте механизм назначения сервисного аккаунта виртуальной машине и получения токена через сервис метаданных.
Дополнительно: настройте локальный файрвол на ВМ так, чтобы только необходимые процессы и пользователи системы имели доступ к сервису метаданных (IP-адрес: 169.254.169.254).

Пример блокирования доступа от всех пользователей, кроме указанного (в данном случае root):
```
sudo iptables --append OUTPUT --proto tcp \
--destination 169.254.169.254 --match owner ! --uid-owner root \
--jump REJECT
```

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

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

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

Откройте консоль 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 VM_ID in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.service_account_id)' | jq -r '.id' 
done;
done;
done

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

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

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

1.6 В сервисе метаданных ВМ отсутствуют облачные ключи в открытом виде

Не записывайте ключи сервисных аккаунтов и другие ключи в метаданные виртуальной машины напрямую. Используйте механизм назначения сервисного аккаунта виртуальной машине и получения токена через сервис метаданных. Чувствительные данные могут находиться в любом поле метаданных, но самое распространенное — user-data (за счет использования в утилите cloud-init).

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

yandex_cloud_iam_cookie_v1 : c1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
Yandex.Cloud Session Cookie
yandex_cloud_iam_token_v1 : t1.[A-Z0-9a-z_-]+[=]{0,2}.[A-Z0-9a-z_-]{86}[=]{0,2}
Yandex.Cloud IAM token
yandex_cloud_iam_api_key_v1 : AQVN[A-Za-z0-9_-]{35,38}
Yandex.Cloud API Keys (Speechkit, Vision, Translate)
yandex_passport_oauth_token : y[0-6]_[-_A-Za-z0-9]{55}
Yandex Passport OAuth token
yandex_cloud_iam_access_secret : YC[a-zA-Z0-9_-]{38}
Yandex.Cloud AWS API compatible Access Secret

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

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

Выполните команду для поиска облачных ключей в сервисе метаданных в открытом виде, на примере Yandex Cloud AWS API Сompatible Access Secret:

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."user-data")| .metadata."user-data" | match("YC[a-zA-Z0-9_\\-]{38}") | .string' && echo $VM_ID
done;
done;
done

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

Выполните команду для поиска облачных ключей в сервисе метаданных в открытом виде, на примере Yandex Cloud IAM token:

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 fhm2i4a72v44kdqaqhid --full --format=json | jq -r '. | select(.metadata."user-data")| .metadata."user-data" | match("t1\\.[A-Z0-9a-z_-]+[=]{0,2}\\.[A-Z0-9a-z_-]{86}[=]{0,2}") | .string'
done;
done;
done

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

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

Удалите ключи из метаданных ВМ, у которых были найдены отклонения:

Консоль управления

CLI

API

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

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Посмотрите описание команды CLI для удаления метаданных:
```
yc compute instance remove-metadata --help
```

Удалите ключи:

yc compute instance remove-metadata <идентификатор_ВМ> --keys <имя_SSH-ключа>

Чтобы удалить SSH-ключи из метаданных ВМ, воспользуйтесь методом REST API updateMetadata для ресурса Instance или вызовом gRPC API InstanceService/UpdateMetadata.

В запросе передайте параметр delete с SSH-ключом.

Пример запроса для REST API

curl \
  --request POST \
  --header "Authorization: Bearer <IAM-токен>" \
  --data '{"delete":["<имя_SSH-ключа>"]}' \
  https://compute.api.cloud.yandex.net/compute/v1/instances/<идентификатор_ВМ>/updateMetadata

1.7 На ВМ отключено получение токена через AWS IMDSv1

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

Изнутри виртуальной машины метаданные доступны в следующих форматах:

Google Compute Engine (поддерживаются не все поля).
Amazon EC2 (поддерживаются не все поля).

Формат Amazon EC2 Instance Metadata Service version 1 (IMDSv1) имеет ряд недостатков. Наиболее критичный из них — это риск компрометации токена сервисного аккаунта через сервис метаданных с помощью SSRF-атаки. Подробности в официальном блоге AWS. В связи с этим AWS выпустили вторую версию сервиса метаданных — IMDSv2.

В Yandex Cloud пока нет поддержки второй версии, поэтому строго рекомендуется технически отключать возможность получения токена сервисного аккаунта через Amazon EC2 сервис метаданных.

Сервис метаданных Google Compute Engine использует дополнительный заголовок для защиты от SSRF и повышения безопасности.

Отключить получение токена сервисного аккаунта через Amazon EC2 сервис метаданных можно с помощью параметра ВМ aws_v1_http_token:DISABLED.

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

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

Выполните команду для поиска ВМ, у которых включено использование IMDSv1 для получения токена:

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 --format=json | jq -r '. | select(.metadata_options.aws_v1_http_token=="ENABLED")' | jq -r '.id' 
done;
done;
done

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

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

В блоке metadata_options задайте параметру aws_v1_http_token значение DISABLED у найденных ВМ:

yc compute instance update <ID_виртуальной_машины> \
  --metadata-options aws-v1-http-token=DISABLED

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

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите в нужный каталог.
В списке сервисов выберите Identity and Access Management.
На панели слева выберите Сервисные аккаунты.
Проверьте список сервисных аккаунтов.
Повторите действия для других каталогов.
Перейдите во вкладку Права доступа на уровнях облаков и каталогов.

Права доступа на уровне организации можно посмотреть только в YC CLI.

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

Выполните команду для отображения всех сервисных аккаунтов организации в формате <id_сервисного_аккаунта>:<имя_сервисного_аккаунта>:

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 SA in $(yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc iam service-account list --folder-id=$FOLDER_ID --format=json  | jq -r '.[].id + ":" + .[].name' 
done;
done;
done

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

export ORG_ID=<ID организации>
yc organization-manager organization list-access-bindings \
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")'

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID  --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID
done;

Просмотрите права доступа сервисного аккаунта на всех каталогах:

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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID  --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $FOLDER_ID
done;
done

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

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

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

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

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите в нужный каталог.
В списке сервисов выберите Identity and Access Management.
На панели слева выберите Сервисные аккаунты.
Нажмите на сервисный аккаунт и перейдите во вкладку Права доступа.
Проверьте права, назначенные на сервисный аккаунт.
Если в списке находятся только валидные администраторы, рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

Посмотрите доступные вам организации и зафиксируйте необходимый 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 yc resource-manager cloud list-access-bindings --id=$CLOUD_ID  --format=json | jq -r '.[] | select(.subject.type=="serviceAccount")' && echo $CLOUD_ID
done;

Выполните команду для отображения всех прав доступа на конкретный сервисный аккаунт как на ресурс:
```
yc iam service-account list-access-bindings \
  --id <ID_сервисного_аккаунта>
```
Если в списке находятся только валидные администраторы, рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

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

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

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

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

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите в нужный каталог.
В списке сервисов выберите Identity and Access Management.
На панели слева выберите Сервисные аккаунты.
Нажмите на нужный сервисный аккаунт и в разделе Свойства ключей доступа проверьте дату создания каждого ключа.
Повторите действия в каждом из своих каталогов.
Если даты создания ключей не старше 90 дней, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

Посмотрите доступные вам организации и зафиксируйте необходимый 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 SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do yc iam access-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at '
done;
done;
done

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

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 SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do yc iam key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at '
done;
done;
done

Проверьте дату создания API-ключей доступа:

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 SA in $(yc iam service-account list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id');
do yc iam api-key list --service-account-id=$SA --format=json | jq -r '.[] | "key_id" + ":" + .id + "," + "sa_id" + ":" + .service_account_id + "," + "created_at" + ":" + .created_at '
done;
done;
done

Если в списке любого типа ключей отсутствуют ключи, у которых дата в поле created_at старше 90 дней, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

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

1.11 Настроена двухфакторная аутентификация для привилегированных аккаунтов

Рекомендуется использовать двухфакторную аутентификацию (2FA) для доступа к облачной инфраструктуре, чтобы избежать рисков, связанных с компрометацией пользовательских учетных записей. Доступ в консоль Yandex Cloud может быть организован с помощью 2FA.

Чтобы подключить двухфакторную аутентификацию, обратитесь к поставщику удостоверений (identity provider) с поддержкой 2FA и настройте SAML-совместимую федерацию удостоверений. В Yandex Cloud нет своего IdP и задача идентификации пользователей решается с помощью внешних сервисов — Яндекс ID или корпоративных систем, интегрированных с помощью федерации удостоверений. Например, если вы используете IdP системы Active Directory или Keycloak, то настройте 2FA в данных системах. Необходимо настроить 2FA как минимум для привилегированных учетных записей облака.

Для аккаунта Яндекс ID настройте 2FA согласно инструкции.

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

Откройте UI Яндекс ID в вашем браузере.
Перейдите на вкладку Безопасность.
Проверьте, что указан способ входа с помощью дополнительного ключа.
Если способ входа с помощью ключа настроен, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.
Если вы используете сторонние IdP, проверьте настройки по инструкциям.

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

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

К привилегированным пользователям Yandex Cloud относятся аккаунты со следующими ролями:

billing.accounts.owner;
admin, назначенная на платежный аккаунт;
organization-manager.organizations.owner;
organization-manager.admin;
resource-manager.clouds.owner;
admin, editor, назначенные на организацию;
admin, editor, назначенные на облако;
admin, editor, назначенные на каталог.

Роль billing.accounts.owner автоматически выдается при создании платежного аккаунта и не может быть переназначена другому пользователю. Роль позволяет выполнять любые действия с платежным аккаунтом.

Роль billing.accounts.owner может быть назначена только аккаунту Яндекс ID. Аккаунт с ролью billing.accounts.owner используется при настройке способов оплаты и подключении облаков.

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

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

Используйте его только при первоначальной настройке и внесении изменений.
На время активного использования данного аккаунта включите двухфакторную аутентификацию (2FA) в Яндекс ID.
Затем, если вы не используете способ оплаты банковской картой (доступный только для данной роли), назначьте данному аккаунту сложный пароль (сгенерированный с помощью специализированного ПО), отключите 2FA и не используйте этот аккаунт без необходимости.
После каждого использования меняйте пароль на сгенерированный заново.

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

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

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

Роль organization-manager.organizations.owner по умолчанию получает владелец организации — пользователь, который ее создал. Роль дает возможность назначать владельцев организации, а также пользоваться всеми полномочиями администратора.

Роль resource-manager.clouds.owner автоматически выдается при создании первого облака в организации. Пользователь с этой ролью может выполнять любые операции с облаком и ресурсами в нем, а также выдавать доступ к облаку другим пользователям: назначать роли и отзывать их.

Назначайте роль resource-manager.clouds.owner и organization-manager.organizations.owner одному или нескольким сотрудникам организации с федеративным аккаунтом. Аккаунту Яндекс ID, с которым создано облако, назначьте сложный пароль и используйте только в случае крайней необходимости, например, при поломке федерации.

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

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

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

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

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

Проверка ролей на сервис Yandex Cloud Billing:

Откройте консоль управления Yandex Cloud в вашем браузере.
Перейдите в сервис Yandex Cloud Billing.
Проверьте кому назначены роли: billing.accounts.owner, admin.

Проверка ролей на организацию:

Откройте консоль управления Yandex Cloud в вашем браузере.
Перейдите во вкладку Все сервисы → Yandex Cloud Organization → Пользователи.
Проверьте кому назначены роли: admin, organization-manager.organizations.owner, organization-manager.admin, resource-manager.clouds.owner.

Проверка ролей на облако:

Откройте консоль управления Yandex Cloud в вашем браузере.
Перейдите в общее меню облака: нажмите на облако в исходном меню облака. Выберите вкладку Права доступа.
Проверьте кому назначены роли: admin, editor , resource-manager.clouds.owner.

Проверка ролей на каталоге:

Откройте консоль управления Yandex Cloud в вашем браузере.
Далее перейдите в каждый каталог каждого облака и по аналогии перейдите во вкладку Права доступа.
Проверьте кому назначена роль admin.
Если все привилегированные роли назначены доверенным администраторам, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

Найдите привилегированные права на уровне организации:

export ORG_ID=<ID организации>
yc organization-manager organization list-access-bindings
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")'

Найдите привилегированные права на уровне облаков:

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="resource-manager.clouds.owner" or role_id=="resource-manager.clouds.editor")' && echo $CLOUD_ID
done

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

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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin")' && echo $FOLDER_ID
done;
done

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

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

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

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

Для работы с БД на прикладном уровне помимо сервисных IAM ролей создается отдельный локальный пользователь — владелец БД. В отношении него действует следующая парольная политика:

пароль должен содержать цифры, буквы в верхнем регистре, буквы в нижнем регистре, специальные символы;
длина пароля — не менее 8 символов.

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

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

1.14 Доступ для подрядных организаций и третьих лиц контролируется

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

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

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

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

1.15 Используется корректная ресурсная модель

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

Как минимум одна организация для компании.
Группировать ресурсы по назначению и помещать их в отдельные каталоги. Для наиболее строгой изоляции — в отдельные облака.
Все критичные ресурсы помещайте в отдельные каталоги или облака. К критичным относятся в том числе ресурсы, которые связаны с обработкой платежных данных, персональных данных, данных коммерческой тайны.
Группы ресурсов, которые требуют различного административного доступа, например, DMZ, CDE, security, backoffice и т. д., поместите в разные каталоги или облака.
При разработке приложений, необходимо разделять тестовые и промышленные среды.
Общие ресурсы (например, сеть и группы безопасности) поместите в отдельный каталог для разделяемых ресурсов (в случае разделения компонентов по каталогам).

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

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

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

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

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

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

Важно

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

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

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

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

Проверка ролей в облаке:

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

Проверка ролей в каталоге:

Откройте консоль управления Yandex Cloud в вашем браузере.
Перейдите в нужный каталог нужного облака и перейдите во вкладку Права доступа.
Проверьте, есть ли среди пользователей All users и All authenticated users.
Повторите действия для всех каталогов всех ваших облаков.

Проверка ролей в Object Storage:

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

Проверка ролей в Container Registry:

Откройте консоль управления Yandex Cloud в вашем браузере.
Далее перейдите в каждое облако и найдите сервис Container Registry.
Перейдите в необходимый реестр и слева нажмите Права доступа.
Проверьте, есть ли среди пользователей All users и All authenticated users.
Повторите действия для всех ваших облаков.

Проверка ролей в Cloud Functions:

Откройте консоль управления Yandex Cloud в вашем браузере.
Далее перейдите в каждое облако и найдите сервис Cloud Functions.
Перейдите во все облачные функции и проверьте, что параметр Публичный доступ выключен.
Если в каждом указанном ресурсе нет субъектов All users и All authenticated users, то рекомендация выполняется. Если есть, то перейдите к п. Инструкции и решения по выполнению.

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

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

export ORG_ID=<ID организации>
yc organization-manager organization list-access-bindings \
  --id=${ORG_ID} \
  --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="organization-manager.organizations.owner" or .role_id=="organization-manager.admin" or .role_id=="resource-manager.clouds.owner")'

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CLOUD_ID
done

Выполните команду для поиска прав доступа allUsers, allAuthenticatedUsers на уровне каталогов:

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

Выполните команду для поиска прав доступа allUsers, allAuthenticatedUsers на уровне Container Registry во всех каталогах:

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-access-bindings --id $CR --format=json | jq -r '.[] | select(.subject.id=="allAuthenticatedUsers" or .subject.id=="allUsers")' && echo $CR
done;
done;
done

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

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

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

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

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

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

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

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

Откройте консоль управления Yandex Cloud в вашем браузере.
Перейдите в сервис Yandex Cloud Billing.
Перейдите во вкладку Данные аккаунта.
В самом низу будет кнопка Редактировать данные в Яндекс Балансе.
Проверьте указанные контактные данные.
Если указанные данные актуальны, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

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

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

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

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

Откройте консоль управления Yandex Cloud в вашем браузере.
Перейдите во вкладку Organizations.
Далее перейдите во вкладку Федерации и выберите вашу федерацию.
Найдите параметр Время жизни cookie.
Если значение этого параметра меньше либо равно 6 часам, то рекомендация выполняется. Если нет, то перейдите к п. Инструкции и решения по выполнению.

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

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

export ORG_ID=<ID организации>
for FED in $(yc organization-manager federation saml list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc organization-manager federation saml get --id bpfdshe1skaqcjp6uc50 --format=json | jq -r '. | select(.cookie_max_age>"21600s")'
done

Если выдается пустая строка, то рекомендация выполняется. Если выдается результат с настройкой текущей федерации, где параметр cookie_max_age > 21600s, то перейдите к п. Инструкции и решения по выполнению.

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

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

1.19 Токен для облачных функций и ВМ выдается через сервисный аккаунт

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

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

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

1.20 Используется имперсонация, где это возможно

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

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

В консоли управления на панели слева нажмите на имя нужного облака.
Перейдите на вкладку Права доступа и проверьте наличие роли iam.serviceAccounts.tokenCreator.

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

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

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

Для отслеживания потоков данных и обозначения критичности ресурсов для управления привилегиями необходимо использование меток.
Например, для тегирования ресурсов, которые обрабатывают персональные данные в рамках Федерального закона Российской Федерации «О персональных данных» № 152-ФЗ нужно выбрать метку 152-fz:true для:

каталога;
бакета Yandex Object Storage;
секрета Yandex Lockbox;
кластеров управляемых баз данных.

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

В примере ниже показана проверка наличия метки к облачной сети Yandex Virtual Private Cloud. Аналогично вы можете проверить наличие метки у другого ресурса.

В консоли управления выберите каталог.
Выберите сервис Virtual Private Cloud.
Проверьте наличие меток.

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

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

1.22 Уведомления безопасности Yandex Cloud включены

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

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

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

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

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

1.23 Используется роль auditor для исключения доступа к данным пользователей

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

Просмотр информации о ресурсе.
Просмотр метаданных ресурса.
Просмотр списка операций с ресурсом.

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

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

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

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

Посмотрите доступные вам организации и зафиксируйте необходимый ID:
```
yc organization-manager organization list
```
Выполните команду для поиска учетных записей с ролью auditor на уровне организации:
```
export ORG_ID=<ID_организации>
yc organization-manager organization list-access-bindings \
--id=${ORG_ID} \
--format=json | jq -r '.[] | select(.role_id=="auditor")'
```
Если в списке отсутствуют учетные записи, то перейдите к п. Инструкции и решения по выполнению.
Выполните команду для поиска учетных записей с ролью auditor на уровне облаков:
```
export ORG_ID=<ID_организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="auditor")'
done
```
Если в списке отсутствуют учетные записи, то перейдите к п. Инструкции и решения по выполнению.

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

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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="auditor")'
done;
done

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

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

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

1.24 Отслеживается дата последнего использования ключей доступа в Yandex Identity and Access Management

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

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

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

В консоли управления перейдите в каталог, которому принадлежит сервисный аккаунт с ключами доступа.
В списке сервисов выберите Identity and Access Management.
На панели слева выберите Сервисные аккаунты.
В открывшемся списке выберите нужный сервисный аккаунт.
Данные о времени последнего использования ключа доступны в таблице с информацией о ключах в поле Дата последнего использования.

2. Сетевая безопасность

В этом разделе представлены рекомендации пользователям по настройкам безопасности в Yandex Virtual Private Cloud.

Подробно о том, как настроить сетевую инфраструктуру, рассказывается в вебинаре Как работает сеть в Yandex Cloud.

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

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

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

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

Список доступных сервисов расширяется.

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

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

Убедитесь, что в ваших облаках используются группы безопасности на каждом объекте облака, либо используется отдельная ВМ NGFW из Cloud Marketplace, либо по принципу «bring your own image» («используй свое устройство» — принцип, позволяющий использовать свое оборудование или образы системы).

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

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

Проверка наличия групп безопасности на объектах:

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

Проверка наличия NGFW вместо групп безопасности:

Откройте консоль управления Yandex Cloud в вашем браузере.
Перейдите в каждое облако и в каждый каталог и последовательно откройте все диски ВМ.
В настройках дисков найдите параметр Продукт Marketplace.
Если в параметрах Продукт Marketplace в диске указано одно из названий продуктов NGFW: Check Point CloudGuard IaaS — Firewall & Threat Prevention PAYG, UserGate NGFW, рекомендация выполняется. Если нет, перейдите к пункту «Инструкции и решения по выполнению».

Посмотрите доступные вам организации и зафиксируйте необходимый 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 yc compute instance get --id=$VM_ID --format=json | jq -r '. | select(.network_interfaces[].security_group_ids | not)' | jq -r '.id'
done;
done;
done

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

Проверка наличия NGFW вместо группы безопасности:

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

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 DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute disk get --id=$DISK_ID --format=json | jq -r '. | select(.product_ids[0]=="f2ecl4ak62mjbl13qj5f" or .product_ids[0]=="f2eqc5sac8o5oic7m99k")' | jq -r '.id'
done;
done;
done

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

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

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

2.2 В Virtual Private Cloud существует как минимум одна группа безопасности

Чтобы назначить группы безопасности на облачные объекты в Virtual Private Cloud, должна существовать как минимум одна группа безопасности. Дополнительно существует возможность создания группы безопасности по умолчанию — такая группа назначается облачным объектам при подключении к подсетям, если у них нет ни одной группы. Убедитесь в том, что хотя бы одна группа безопасности существует в каждой сети.

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите в каждое облако, далее в каждый каталог и в каждую Virtual Private Cloud.
Перейдите в раздел Группы безопасности.
Если обнаружена как минимум одна группа безопасности для каждой Virtual Private 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 echo "SG_ID: " && yc vpc security-group list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.id)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done

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

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

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

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

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

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

Важно

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

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите в каждое облако, далее в каждый каталог и в каждую Virtual Private 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 echo "SG_ID: " && yc vpc security-group list --folder-id=$FOLDER_ID \
--format=json | jq -r '.[] | select(.rules[].direction=="INGRESS" and .rules[].ports.to_port=="65535" and .rules[].cidr_blocks.v4_cidr_blocks[]=="0.0.0.0/0")' | jq -r '.id' \
&& echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done

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

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

Удалите опасное правило в каждой группе безопасности или отредактируйте, указав доверенные IP-адреса.

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

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

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите в каждое облако, далее в каждый каталог и в каждую Virtual Private 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 echo "SG_ID: " && yc vpc security-group list --folder-id=$FOLDER_ID \
--format=json | jq -r '.[] | select(.rules[].direction=="INGRESS" and (.rules[].ports.to_port=="22" or .rules[].ports.to_port=="3389" or .rules[].ports.to_port=="21") and .rules[].cidr_blocks.v4_cidr_blocks[]=="0.0.0.0/0")' | jq -r '.id' \
&& echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done

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

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

Удалите опасное правило в каждой группе безопасности или укажите доверенные IP-адреса.

2.5 Включена защита от DDoS атак

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

Yandex DDoS Protection — это компонент сервиса Virtual Private Cloud для защиты облачных ресурсов от DDoS-атак. DDoS Protection предоставляется в партнерстве с Qrator Labs. Вы можете включать ее самостоятельно на внешний IP-адрес через инструменты управления облаком. Работает до L4 уровня модели OSI.
Расширенная защита от DDoS-атак — работает на 3 и 7 уровнях модели OSI. Вы также можете отслеживать показатели нагрузки, параметры атак и подключить Solidwall WAF в личном кабинете Qrator Labs. Чтобы включить расширенную защиту, обратитесь к вашему менеджеру или в техническую поддержку.

Проверка в консоли управления (базовая защита)

Ручная проверка (расширенная защита)

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

Откройте консоль Yandex Cloud в вашем браузере.
Откройте все созданные сети.
Перейдите в раздел IP-адреса.
Если у всех публичных адресов в столбце Защита от DDoS-атак установлено значение Включена, рекомендация выполняется. Если нет, перейдите к пункту «Инструкции и решения по выполнению».

Обратитесь к вашему персональному менеджеру и уточните, подключена ли у вас расширенная защита от DDoS-атак.

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

Выполните команду для поиска IP-адресов без защиты от DDoS:

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 echo "Address_ID: " && yc vpc address list --folder-id=$FOLDER_ID \
--format=json | jq -r '.[] | select(.external_ipv4_address.requirements.ddos_protection_provider=="qrator" | not)' | jq -r '.id' \
&& echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done

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

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

Вебинар Защита от DDoS в Yandex Cloud.
Все материалы по защите от DDoS в Yandex Cloud.

2.6 Используется защищенный удаленный доступ

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

Site-to-site VPN между удаленной площадкой (например, вашим офисом) и облаком. В качестве шлюза для удаленного доступа используйте ВМ с функцией site-to-site VPN на основе образа из Cloud Marketplace.

Варианты настройки:
- Создание туннеля IPSec VPN с использованием демона strongSwan.
- Создание site-to-site VPN-соединения с Yandex Cloud с помощью Terraform.
- Client VPN между удаленными устройствами и Yandex Cloud. В качестве шлюза для удаленного доступа используйте ВМ с функцией client VPN на основе образа из Cloud Marketplace.
См. инструкцию в разделе Создание VPN-соединения с помощью OpenVPN. Возможно так же использование сертифицированных СКЗИ.
Приватное выделенное соединение между удаленной площадкой и Yandex Cloud c помощью сервиса Cloud Interconnect.

Для доступа в инфраструктуру по управляющим протоколам (например, SSH, RDP) рекомендуется создать бастионную ВМ. Для этого можно использовать бесплатное решение Teleport. Доступ к бастионной ВМ или VPN-шлюзу из интернета должен быть ограничен.

Для дополнительного контроля действий администраторов рекомендуется использовать решения PAM (Privileged Access Management) с записью сессии администратора (например, Teleport). Для доступа по SSH и VPN рекомендуется отказаться от паролей и вместо этого использовать открытые ключи, X.509-сертификаты и SSH-сертификаты. При настройке SSH для ВМ рекомендуется использовать SSH-сертификаты, в том числе и для хостовой части SSH.

Для доступа к веб-сервисам, развернутым в облаке, рекомендуется использовать TLS версий 1.2 и выше.

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

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

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

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

2.7 Исходящий доступ в интернет контролируется

Возможные варианты организации исходящего доступа в интернет:

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

Сравнение способов доступа в интернет:

Публичный IP-адрес	Egress NAT	NAT-инстанс
Плюсы:	Плюсы:	Плюсы:
Не требует настройки Выделенный адрес для каждой ВМ	Не требует настройки Работает только на исходящих соединениях	Возможность фильтровать трафик на NAT-инстансе Возможность использовать собственный файрвол Экономия IP-адресов
Минусы:	Минусы:	Минусы:
Выставлять ВМ напрямую в интернет может быть небезопасно Стоимость резервирования каждого адреса	Общий пул IP-адресов Функция на стадии Preview, поэтому не рекомендуется для продуктовых сред	Требуется настройка Стоимость использования ВМ (vCPU, RAM, диска)

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

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

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

Откройте консоль Yandex Cloud в вашем браузере.
Перейдите в нужный каталог.
Перейдите в раздел IP-адреса.
Если у всех публичных адресов в столбце Защита от DDoS-атак установлено значение Включена, рекомендация выполняется. В противном случае перейдите к пункту «Инструкции и решения по выполнению».

Посмотрите доступные вам организации и зафиксируйте необходимый 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 echo "VM_ID: " && yc compute instance list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.network_interfaces[].primary_v4_address.one_to_one_nat.address)' | jq -r '.id' \
&& echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done

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

Выполните команду для поиска наличия Egress NAT (NAT-шлюз):

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 echo "NAT_GW: " && yc vpc gateway list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.id)' | jq -r '.id' && echo "FOLDER_ID: " $FOLDER_ID && echo "-----"
done;
done

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

Выполните команду для поиска наличия NAT-инстанса:

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 DISK_ID in $(yc compute disk list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); do yc compute disk get --id=$DISK_ID --format=json | jq -r '. | select(.product_ids[0]=="fd8v7ru46kt3s4o5f0uo")' | jq -r '.id'
done;
done;
done

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

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

В случае наличия публичных адресов на ВМ убедитесь, что они необходимы. В противном случае удалите внешний IP-адрес в настройках ВМ.
В случае наличия NAT-Gateway убедитесь, что он необходим. В противном случае удалите его.
В случае наличия NAT-инстанс убедитесь, что он необходим. В противном случае удалите его.

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

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

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

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

Общее

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

На виртуальных машинах доступ к серийной консоли по умолчанию отключен. Риски использования серийной консоли перечислены в разделе Начало работы с серийной консолью документации 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.2 Используется эталонный образ для развертывания ВМ

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

Подготовить образ виртуальной машины, настройки системы в котором соответствуют вашей политике информационной безопасности. Создать образ можно с помощью 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.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 с поддержкой 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 происходит на трёх уровнях:

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

Если запрос прошел проверку 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.7 В 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.8 В 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.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.

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-адресов, см. инструкцию в разделе Создать группу безопасности. Указать группу безопасности можно в настройках кластера или при его создании, в блоке сетевых настроек.

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

Проверка через 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.14 На управляемых базах данных не назначен публичный 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.15 Включена настройка защиты от удаления (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.16 Выключена настройка доступа из 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.17 На управляемых БД выключен доступ из консоли управления

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

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

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

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

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

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

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

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

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

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

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

Проверка через 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.

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.

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

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

Проверка через 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.26 Учтены рекомендации по резервному копированию YDB

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

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

Yandex Container Registry

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

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

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

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

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

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

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

Проверка через 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.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 дней.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Шифрование данных и управление ключами

Введение

Yandex Cloud предоставляет встроенные функции шифрования при использовании ряда сервисов. В зоне ответственности клиента находится включение шифрования в этих сервисах, а также самостоятельная реализация шифрования в других компонентах обработки критичных данных. Для шифрования данных и управления ключами шифрования предназначен сервис Key Management Service (KMS).

API сервисов Yandex Cloud поддерживают наборы алгоритмов (cipher suits) и версии протокола TLS, отвечающие требованиям стандарта PCI DSS и другим стандартам.

Шифрование в состоянии покоя (at rest)

По умолчанию все пользовательские данные в состоянии покоя (at rest) зашифрованы на уровне Yandex Cloud. Шифрование на уровне Yandex Cloud является реализацией одной из лучших практик по защите данных пользователей и выполняется на ключах Yandex Cloud.

Если ваша корпоративная политика информационной безопасности предъявляет требования к длине ключа или частоте ротации ключей, вы можете шифровать данные собственными ключами. Для этого можно использовать сервис KMS и его интеграцию с другими сервисами Yandex Cloud, либо реализовать шифрование на data plane-уровне полностью самостоятельно.

Yandex Cloud предоставляет функции шифрования в состоянии покоя (at rest) для следующих сервисов:

Object Storage;
Managed Service for Kubernetes.

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

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

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

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

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

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

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

aws --endpoint-url=https://storage.yandexcloud.net/ \
s3api get-bucket-encryption \
--bucket <имя бакета>

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

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

Настройте шифрование бакета согласно инструкции.

Шифрование в состоянии передачи (in transit)

В большинстве случаев соединение с сервисами Yandex Cloud возможно только с использованием HTTPS. Однако в некоторых сценариях data plane доступ к сервисам может быть осуществлен и по HTTP, без шифрования соединения на прикладном уровне. Во всех таких сценариях у пользователя есть возможность выбрать в настройках сервиса, какой протокол использовать при data plane-операциях: HTTP или HTTPS, а в случае выбора HTTPS указать собственный TLS-сертификат.

Примечание

Убедитесь, что используете для работы (или соединения) с API сервисов Yandex Cloud протокол TLS версии 1.2 и выше, так как более ранние версии подвержены уязвимостям.

Например, использование gRPC-интерфейсов Yandex Cloud гарантирует работу по TLS 1.2 и выше, так как протокол HTTP/2, на основе которого работает gRPC, устанавливает TLS 1.2 в качестве минимальной поддерживаемой версии протокола TLS.

Поддержка устаревших протоколов TLS в сервисах Yandex Cloud будет постепенно прекращена.

Yandex Cloud предоставляет возможность использования собственных TLS-сертификатов для следующих сервисов:

Object Storage;
Application Load Balancer;
API Gateway;
Cloud CDN.

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ALB in $(yc application-load-balancer load-balancer list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc application-load-balancer load-balancer get --id $ALB --format json | jq -r '. | select(.listeners[0].tls | not)' | jq -r '.id'
done;
done;
done

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

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

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

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

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

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

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

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

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

Выполните команду для вывода списка всех api gateway без подключенных доменов и сертификатов:

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 APIGW in $(yc serverless api-gateway list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc serverless api-gateway get --id $APIGW --format json | jq -r '. | select(.attached_domains[0].certificate_id | not)' | jq -r '.id'
done;
done;
done

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

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

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

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

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

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

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

В консоли управления выберите облако или каталог, в которых необходимо проверить ресурсы.
В списке сервисов выберите Cloud CDN.
Перейдите в настройки ресурса, на вкладку Дополнительно.
Убедитесь, что в поле Протокол для источников указан протокол HTTPS.
Убедитесь, что в поле Сертификат указан собственный сертификат либо Let’s encrypt.
Если указан HTTPS и собственный сертификат, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

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

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 CDN in $(yc cdn resource list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc cdn resource get --id $CDN --format json | jq -r '. | select(.origin_protocol=="HTTPS" and .ssl_certificate.type=="CM" | not)' | jq -r '.id' 
done;
done;
done

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

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

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

Самостоятельное шифрование

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

4.6 Для критичных данных используется шифрование MDB с помощью KMS

Если шифрование данных необходимо, следует шифровать их на уровне приложения перед записью в базы данных, например, с помощью KMS и дополнительных надстроек, например pgcrypto.

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

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

Убедитесь, что данные хранятся в зашифрованном виде.

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

yc managed-postgresql database get <database_name> --cluster-id <managed_postgre_cluster_id> --format=json | jq -r '.extensions | .[].name'

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

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

Инструкцию о шифровании данных в Yandex Managed Service for PostgreSQL и Yandex Managed Service for Greenplum® с помощью pgcrypto см. в разделе Использование pgcrypto в Managed Service for Greenplum®.

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

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

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

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

AWS Encryption SDK и его интеграцию с KMS;
Google Tink и ее интеграцию с KMS;
SDK Yandex Cloud вместе с любой другой криптографической библиотекой, совместимой с PCI DSS или другими стандартами, применяемыми в вашей компании.

Сравнение библиотек представлено в разделе Какой способ шифрования выбрать документации KMS.

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

Убедитесь, что данные хранятся в зашифрованном виде.

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

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

Рекомендуем также использовать шифрование дисков и снимков дисков с помощью пользовательских симметричных ключей Yandex Key Management Service. Такой подход позволяет:

Защищаться от потенциальных угроз нарушения изоляции и компрометации данных на уровне виртуальной инфраструктуры.
Контролировать шифрование и жизненный цикл ключей KMS, а также управлять ими. Подробнее см. в разделе Управление ключами.
Повысить уровень контроля доступа к данным на диске за счет необходимости прав на ключ KMS. Подробнее см. в разделе Настройка прав доступа к симметричному ключу шифрования.
Отслеживать операции шифрования и расшифрования вашим ключом KMS с помощью сервиса Yandex Audit Trails. Подробнее см. в разделе Аудит использования ключей.

Вы можете зашифровать диски следующих типов:

Сетевой SSD-диск (network-ssd).
Сетевой HDD-диск (network-hdd).
Нереплицируемый SSD-диск (network-ssd-nonreplicated).
Сверхбыстрое сетевое хранилище с тремя репликами (SSD) (network-ssd-io-m3).

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

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

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

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

Управление ключами

Для шифрования данных и управления ключами рекомендуется использовать Key Management Service. KMS предназначен для защиты данных в инфраструктуре Yandex Cloud, а также подходит для шифрования и расшифровки любых ваших данных.

KMS использует схему шифрования AES-GCM. Вы можете выбрать длину ключа: 128, 192 или 256 — и настроить период ротации ключей в зависимости от своих потребностей.

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

В продакшн-среде рекомендуется использовать отдельные ключи, все крипто-операции с которыми будут выполняться только внутри специализированного аппаратного устройства. Подробнее см. статью Аппаратный модуль безопасности (HSM).

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

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

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

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

В консоли управления выберите облако или каталог, в которых необходимо проверить ключи.
В списке сервисов выберите Key Management Service.
Перейдите на вкладку Ключи.
Убедитесь, что в поле Алгоритм шифрования указан AES-256 HSM.
Если указан AES-256 HSM, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

Выполните команду для вывода списка всех ключей KMS организации и их алгоритмов шифрования:

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 yc kms symmetric-key list --folder-id=$FOLDER_ID --format json | jq -r '.[] | "KEY_ID " + .id + "FOLDER_ID " + .folder_id + "ALGORITM_ID " + .default_algorithm' 
done;
done

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

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

Установите алгоритм шифрования для ключей KMS «AES-256 HSM».

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

Для доступа к сервису KMS необходимо использовать IAM-токен.

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

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

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

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

на организацию, облако, каталоги с правами: admin, editor, kms.admin, kms.editor, kms.keys.encrypterDecrypter;
на ключи: kms.keys.encrypterDecrypter и kms.editor.

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

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

В консоли управления выберите облако или каталог, в которых необходимо проверить права на ключ.
Перейдите на вкладку Права доступа.
Убедитесь, что роли admin, editor, kms.admin, kms.editor, kms.keys.encrypterDecrypter имеют только контролируемые пользователи.
Проверить права доступа к самим ключам возможно только через CLI.

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

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

export ORG_ID=<ID организации>
yc organization-manager organization list-access-bindings --id=${ORG_ID} --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")'

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

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do yc resource-manager cloud list-access-bindings --id=$CLOUD_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")'
done

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

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 yc resource-manager folder list-access-bindings --id=$FOLDER_ID --format=json | jq -r '.[] | select(.role_id=="admin" or .role_id=="editor" or .role_id=="kms.admin" or .role_id=="kms.editor" or .role_id=="kms.keys.encrypterDecrypter")' && echo $FOLDER_ID
done;
done

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

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

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 KEY in $(yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc kms symmetric-key list-access-bindings --id $KEY --format json 
done;
done;
done

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

Проконтролируйте, кому предоставлен доступ к ключам KMS.

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

Выполните команду для вывода списка всех ключей KMS организации и их алгоритмов шифрования:

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 yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.rotation_period | not)' | jq -r '.id' 
done;
done

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

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

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

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

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

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

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

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

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

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

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 yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[] | select(.deletion_protection | not)' | jq -r '.id' 
done;
done

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

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

Установите защиту от удаления.

Управление секретами

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

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

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

Инструкции по работе с сервисом см. в документации Lockbox.

Vault позволяет использовать KMS в качестве доверенного сервиса для шифрования секретов. Реализуется это через механизм Auto Unseal.

Для хранения секретов с помощью Vault можно использовать виртуальную машину на основе образа из Cloud Marketplace с предустановленной сборкой HashiCorp Vault и поддержкой Auto Unseal. Инструкция по настройке Auto Unseal приведена в статье Auto Unseal в Hashicorp Vault документации KMS.

Примечание

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

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

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

В консоли управления выберите облако или каталог, в которых необходимо проверить секреты.
В списке сервисов выберите Lockbox.
Убедитесь, что используется как минимум один секрет Lockbox.
Найдите параметр Защита от удаления.
Если используется Lockbox, либо среди виртуальных машин или сущностей Kubernetes находится установленный Hashicorp Vault, рекомендация выполняется. В противном случае перейдите к п. «Инструкции и решения по выполнению».

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

Выполните команду для поиска как минимум одного секрета Lockbox:

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 yc lockbox secret list --folder-id=$FOLDER_ID --format=json 
done;
done

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

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

Храните секреты в Lockbox либо Hashicorp Vault из Marketplace.

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

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

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

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

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

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

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

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

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

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

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

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

Удалите секретные данные из env и воспользуйтесь функционалом интеграции с Lockbox.

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

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

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

Шифрование секретов в Terraform для передачи на ВМ с Container Optimized Image.

Другие рекомендации по безопасному использованию Terraform см. в статье Безопасная конфигурация: Terraform.

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

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

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

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

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

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

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

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

Убедитесь, что:

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

5. Сбор, мониторинг и анализ аудитных логов

Введение

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

События в аудитных логах относятся к различным уровням:

уровень Yandex Cloud — события, происходящие с ресурсами Yandex Cloud;
уровень ОС;
уровень приложений;
уровень сети (Flow Logs).

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В консоли управления выберите облако или каталог, в которых необходимо проверить функции.
В списке сервисов выберите Yandex Audit Trails.
Убедитесь, что в параметре Фильтр находится значение Организация.
Дополнительно убедитесь, что назначение логов: bucket Yandex Object Storage, лог-группа Cloud Logging, Data Streams в рабочем состоянии и логи доступны для дальнейшего анализа.

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

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

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

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

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

поиск событий Yandex Cloud в Yandex Query;
поиск событий Yandex Cloud в Cloud Logging;
поиск событий Yandex Cloud в Object Storage.

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

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

5.3 Настроено реагирование на события Yandex Audit Trails

Вы можете реагировать на события Yandex Audit Trails средствами вашей SIEM системы либо вручную. Либо вы можете использовать автоматическое реагирование.

C помощью Yandex Cloud Functions можно настроить оповещения о событиях Audit Trails, а так же автоматическое реагирование на вредоносные действия, например удаление опасных правил или прав доступа.

Решение: уведомления и реагирование на события ИБ Audit Trails с помощью IAM / Cloud Functions + Telegram

5.4 Выполнен hardering бакета Object Storage, где хранятся аудит логи Yandex Audit Trails

Убедитесь, что в случае записи аудит логов Yandex Audit Trails в bucket Yandex Object Storage сам бакет настроен в соответствии с лучшими практиками безопасности:

4.1 В Yandex Object Storage включено шифрование данных at rest с помощью ключа KMS.
3.8 В Yandex Object Storage включен механизм логирования действий с бакетом.
3.8 В Yandex Object Storage включена функция Блокировка версии объекта (object lock).
3.7 В Yandex Object Storage используются политики доступа (Bucket Policy).
3.6 Отсутствует публичный доступ к бакету Yandex Object Storage.

Вы можете воспользоваться решением для настройки безопасного бакета Yandex Object Storage с помощью Terraform.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.7 Выполняется сбор логов с уровня сети

Запись событий о сетевом трафике VPC (Flow Logs) на текущий момент может выполняться только средствами клиента. Для сбора и передачи событий могут использоваться решения из Yandex Cloud Marketplace (например, NGFW, IDS/IPS, сетевые продукты) либо бесплатное ПО. Также сбор логов уровня сети возможно выполнять с помощью различных агентов — HIDS и др.

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

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

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

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

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

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

Список поддерживаемых сервисов:

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

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

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

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

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

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

7. Физическая безопасность

Платформа Yandex Cloud обеспечивает физическую безопасность дата-центров, см. подробное описание мер физической безопасности.

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

8. Защита приложений

9. Безопасность Kubernetes

Введение

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

Все действия внутри узла Kubernetes являются ответственностью пользователя. Пользователь несет ответственность за безопасность узлов и их корректную настройку в соответствии с требованиями PCI DSS и других стандартов безопасности.

За безопасность API Kubernetes отвечает Yandex Cloud.

Пользователь отвечает за правильный выбор настроек безопасности Managed Service for Kubernetes, в том числе выбор канала и расписания обновлений.

9.1 Ограничено использование критичных данных

При работе с сервисом Managed Service for Kubernetes для выполнения требований PCI DSS и других стандартов безопасности запрещается:

Использовать критичные данные в именах и описаниях кластеров, групп узлов, пространств имен, сервисов, подов.
Использовать критичные данные в метках узлов Kubernetes и метках ресурсов сервисов Yandex Cloud.
Указывать критичные данные в манифестах подов.
Указывать критичные данные в etcd в открытом виде.
Записывать критичные данные в логи Managed Service for Kubernetes.

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

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

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

В консоли управления выберите каталог, в котором расположен инстанс Managed Service for Kubernetes.
В списке сервисов выберите Managed Service for Kubernetes.
Убедитесь, что в метках узлов Kubernetes и метках ресурсов сервисов Yandex Cloud нет критичных данных.

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

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

9.2 Ресурсы изолированы друг от друга

Придерживайтесь максимальной изоляции между ресурсами везде, где это возможно:

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

Возможны и менее строгие схемы изоляции, например:

Проекты развернуты в разных облаках.
Команды разработки используют отдельные каталоги.
Сервис представлен отдельным кластером Kubernetes.
Микросервисы используют разные пространства имен.

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

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

9.3 Нет доступа к API Kubernetes и группам узлов из недоверенных сетей

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

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

Инструкция по созданию кластра без доступа в интернет.
Инструкция по настройке групп безопасности.
Используйте инструменты для настройки network policy с помощью плагинов Calico (базовый) или Cilium CNI (продвинутый) в Yandex Cloud, используя default deny правила для входящего и исходящего трафика по умолчанию и разрешать только необходимый трафик.
Выделите отдельный кластер Kubernetes для конечных точек, которые взаимодействуют с интернетом, либо отдельные группы узлов (с помощью механизмов: Taints and Tolerations + Node affinity). Таким образом, выделяется DMZ, и в случае компрометации узлов из интернета поверхность атаки ограничится.
Чтобы организовать входящий сетевой доступ к рабочим нагрузкам по протоколу HTTP/HTTPS используйте ресурс Ingress. Существует как минимум 2 варианта Ingress-контроллера, которые можно использовать в Yandex Cloud:
- NGINX Ingress Controller.
- Application Load Balancer Ingress-контроллера.

9.4 В Managed Service for Kubernetes настроены аутентификация и управление доступом

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

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

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

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

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

В Managed Service for Kubernetes пользователь управляет всеми настройками групп узлов, настройками мастера — только частично. Пользователь отвечает за безопасность всего кластера.

Для безопасной конфигурации Kubernetes, включая конфигурацию узлов, существует стандарт CIS Kubernetes Benchmark. В Yandex Cloud группы узлов Kubernetes по умолчанию разворачиваются с конфигурацией, которая соответствует стандарту CIS Kubernetes Benchmark.

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

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

9.6 Шифрование данных и управление секретами Managed Service for Kubernetes выполняются в формате ESO as a Service

Шифрование секретов на уровне Kubernetes etcd необходимо выполнять встроенным механизмом сервиса Yandex Cloud.

Работу с Kubernetes secrets рекомендуется выполнять с помощью решений класса SecretManager. В Yandex Cloud таким решением является сервис Yandex Lockbox.

Интеграция Yandex Lockbox с Kubernetes выполнена с помощью открытого проекта External Secrets. Решение доступно в Cloud Marketplace в базовом упрощенном сценарии — External Secrets Operator с поддержкой Yandex Lockbox.

Рекомендуемый наиболее безопасный вариант шифрования секретов — ESO as a Service (External Secrets Operator as a service). При использовании ESO глобальный администратор имеет доступ к пространству имен с установленным ESO, а администраторы отдельных пространств имен создают себе объекты SecretStore (в которых указывают IAM авторизованные ключи доступа к своим секретам Lockbox). В случае компрометации данного объекта SecretStore скомпрометирован будет только авторизованный ключ одного пространства имен, а не всех как в случае, например, схемы Shared ClusterSecretStore.

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

9.7 Docker-образы хранятся в реестре Container Registry с настроенным периодическим сканированием образов

Для эффективного обеспечения безопасности рекомендуется использовать Container Registry для хранения Docker-образов, которые разворачиваются в Managed Service for Kubernetes. Это позволит оперативно реагировать на появление новых уязвимостей в образах с помощью встроенного переодического сканирования на уязвимости.

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

Использование Container Registry для хранения образов также обеспечит централизованное управление версиями образов, что упростит процесс обновления и управления безопасностью.

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

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

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

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

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

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

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

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

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

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

Чтобы узнать список доступных версий для кластера Kubernetes:

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

Чтобы узнать список доступных версий для группы узлов Kubernetes:

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

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

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

yc managed-kubernetes list-versions

Чтобы получить список доступных версий, воспользуйтесь методом list.

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

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

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

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

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

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

Вы можете создавать резервные копии данных из групп узлов кластера Kubernetes с помощью инструмента Velero. Этот инструмент поддерживает работу с дисками Yandex Cloud с помощью CSI-драйвера Kubernetes, и позволяет создавать моментальные снимки дисков томов.

При работе с Velero, установленным вручную, вы можете использовать nfs, emptyDir, локальный или любой другой тип тома, в котором нет встроенной поддержки моментальных снимков. Чтобы использовать такой тип тома, задействуйте плагин restic при установке Velero. Velero, установленный из Cloud Marketplace, плагин restic не включает.

Инструкция по резервному копированию кластера Kubernetes в Object Storage.

9.10 Используются чек-листы для безопасного создания и использования Docker-образа

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

Контролировать Dockerfile в процессе CI/CD можно с помощью утилиты Conftest.

При проверке минимальных образов или образов distroless (distroless images), в которых отсутствует shell, рекомендуется использовать ephemeral cointainers.

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

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

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

Требования Pod Security Standards от Kubernetes позволяют предотвращать угрозы, связанные с объектами Kubernetes, такие как несанкционированный доступ к конфиденциальным данным или выполнение вредоносного кода.

Эти требования помогают обеспечить безопасность и надежность работы приложений в кластере Kubernetes. Для их реализации можно использовать встроенный инструмент Kubernetes Pod Security Admission Controller или открытое программное обеспечение, например, OPA Gatekeeper или Kyverno.

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

Проверьте выполнение требований Pod Security Standards от Kubernetes.

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

Для контроля соответствия требованиям Pod Security Standarts также можно использовать следующие инструменты в рамках CI/CD:
- Kyverno CLI
- The gator CLI
Инструмент Kubesec.

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

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

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

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

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

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

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

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

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

ClickHouse® является зарегистрированным товарным знаком ClickHouse, Inc.

Стандарт по защите облачной инфраструктуры Yandex Cloud 1.2

ВведениеВведение

Область примененияОбласть применения

Структура стандартаСтруктура стандарта

Требования и подготовкаТребования и подготовка

Ограничение ответственностиОграничение ответственности

Термины и сокращенияТермины и сокращения

1. Аутентификация и управление доступом1. Аутентификация и управление доступом

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

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

1.2 Учетные записи Яндекс ID используются только в исключительных случаях1.2 Учетные записи Яндекс ID используются только в исключительных случаях

1.3 Только необходимые администраторы управляют членством в IAM-группах1.3 Только необходимые администраторы управляют членством в IAM-группах

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

1.5 Облачные сущности с сервисными аккаунтами учтены и ограничены1.5 Облачные сущности с сервисными аккаунтами учтены и ограничены

1.6 В сервисе метаданных ВМ отсутствуют облачные ключи в открытом виде1.6 В сервисе метаданных ВМ отсутствуют облачные ключи в открытом виде

1.7 На ВМ отключено получение токена через AWS IMDSv11.7 На ВМ отключено получение токена через AWS IMDSv1

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

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

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

1.11 Настроена двухфакторная аутентификация для привилегированных аккаунтов1.11 Настроена двухфакторная аутентификация для привилегированных аккаунтов

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

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

1.14 Доступ для подрядных организаций и третьих лиц контролируется1.14 Доступ для подрядных организаций и третьих лиц контролируется

1.15 Используется корректная ресурсная модель1.15 Используется корректная ресурсная модель

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

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

1.18 Таймаут жизни cookie в федерации меньше 6 часов1.18 Таймаут жизни cookie в федерации меньше 6 часов

1.19 Токен для облачных функций и ВМ выдается через сервисный аккаунт1.19 Токен для облачных функций и ВМ выдается через сервисный аккаунт

1.20 Используется имперсонация, где это возможно1.20 Используется имперсонация, где это возможно

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

1.22 Уведомления безопасности Yandex Cloud включены1.22 Уведомления безопасности Yandex Cloud включены

1.23 Используется роль auditor для исключения доступа к данным пользователей1.23 Используется роль auditor для исключения доступа к данным пользователей

2. Сетевая безопасность2. Сетевая безопасность

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

2.2 В Virtual Private Cloud существует как минимум одна группа безопасности2.2 В Virtual Private Cloud существует как минимум одна группа безопасности

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

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

2.5 Включена защита от DDoS атак2.5 Включена защита от DDoS атак

2.6 Используется защищенный удаленный доступ2.6 Используется защищенный удаленный доступ

2.7 Исходящий доступ в интернет контролируется2.7 Исходящий доступ в интернет контролируется

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

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

ОбщееОбщее

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

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

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

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

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

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

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

Yandex Object StorageYandex Object Storage

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

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

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

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

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

Managed Services for DatabasesManaged Services for Databases

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

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

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

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

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

Cloud Functions и Yandex API GatewayCloud Functions и Yandex API Gateway

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

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

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

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

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

Managed Service for YDBManaged Service for YDB

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

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

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

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

Yandex Container RegistryYandex Container Registry

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

Yandex Container SolutionYandex Container Solution

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

Yandex Managed Service for GitLabYandex Managed Service for GitLab

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

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

Введение

Область применения

Структура стандарта

Требования и подготовка

Ограничение ответственности

Термины и сокращения

1. Аутентификация и управление доступом

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

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

1.2 Учетные записи Яндекс ID используются только в исключительных случаях

1.3 Только необходимые администраторы управляют членством в IAM-группах

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

1.5 Облачные сущности с сервисными аккаунтами учтены и ограничены

1.6 В сервисе метаданных ВМ отсутствуют облачные ключи в открытом виде

1.7 На ВМ отключено получение токена через AWS IMDSv1

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

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

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

1.11 Настроена двухфакторная аутентификация для привилегированных аккаунтов

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

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

1.14 Доступ для подрядных организаций и третьих лиц контролируется

1.15 Используется корректная ресурсная модель

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

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

1.18 Таймаут жизни cookie в федерации меньше 6 часов

1.19 Токен для облачных функций и ВМ выдается через сервисный аккаунт

1.20 Используется имперсонация, где это возможно

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

1.22 Уведомления безопасности Yandex Cloud включены

1.23 Используется роль auditor для исключения доступа к данным пользователей

2. Сетевая безопасность

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

2.2 В Virtual Private Cloud существует как минимум одна группа безопасности

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

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

2.5 Включена защита от DDoS атак

2.6 Используется защищенный удаленный доступ

2.7 Исходящий доступ в интернет контролируется

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

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

Общее

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

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

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

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

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

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

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

Yandex Object Storage

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

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

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

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

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

Managed Services for Databases

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

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

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

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

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

Cloud Functions и Yandex API Gateway

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

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

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

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

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

Managed Service for YDB

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

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

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

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

Yandex Container Registry

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

Yandex Container Solution

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

Yandex Managed Service for GitLab

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

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

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