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

ВведениеВведение

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

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

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

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

• Application Load Balancer
• Audit Trails
• Certificate Manager
• Cloud DNS
• Cloud Logging
• Cloud Organization
• Compute Cloud
• Identity and Access Management (IAM)
• Key Management Service
• Managed Service for ClickHouse®
• Managed Service for GitLab
• Managed Service for Kubernetes
• Managed Service for MongoDB
• Managed Service for MySQL®
• Managed Service for PostgreSQL
• Yandex Managed Service for Valkey™
• Managed Service for YDB
• Network Load Balancer
• Object Storage
• Resource Manager
• Virtual Private Cloud
• Yandex Lockbox

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Аутентификация и управление доступом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)1.1 Настроена федерация удостоверений (Single Sign-On, SSO)

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

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

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

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

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

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

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

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

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

1.2 Учетные записи Яндекс ID используются только в исключительных случаях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.

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

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

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

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

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

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

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

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

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

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

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

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

1.5 Облачные сущности с сервисными аккаунтами учтены и ограничены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
  

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

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

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

1.6 В сервисе метаданных ВМ отсутствуют облачные ключи в открытом виде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

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

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

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

1.7 На ВМ отключено получение токена через AWS IMDSv11.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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Двухфакторная аутентификация — Яндекс ID.
• KeyCloak — Creating other credentials.
• Configure Additional Authentication Methods for AD FS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.18 Таймаут жизни cookie в федерации меньше 6 часов1.18 Таймаут жизни cookie в федерации меньше 6 часов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вебинар Защита от DDoS в Yandex Cloud.

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

2.6 Используется защищенный удаленный доступ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 и выше.

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

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

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

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

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

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

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

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

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

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

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

ОбщееОбщее

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

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

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

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

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

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

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

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

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

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

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

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

3.3 Инструмент Terraform используется в соответствии с лучшими практиками ИБ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.

• Пример: сканирование tf-файлов с помощью Checkov.
• Пример: хранение состояния Terraform в Object Storage.

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

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

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

• Wazuh
• Osquery

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

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

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

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

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

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

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

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

Yandex Object StorageYandex Object Storage

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры Bucket Policy:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.9 В Object Storage включен механизм логирования действий с бакетом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)3.10 В Object Storage настроено управление кросс-доменными запросами (CORS)

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

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

Настройте CORS.

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

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

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

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

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

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

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

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

Managed Services for DatabasesManaged Services for Databases

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud Functions и Yandex API GatewayCloud Functions и Yandex API Gateway

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Managed Service for YDBManaged Service for YDB

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

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

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

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

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

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

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

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

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

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

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

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

Yandex Container RegistryYandex Container Registry

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

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

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

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

Yandex Container SolutionYandex Container Solution

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

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

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

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

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

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

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

Yandex Managed Service for GitLabYandex Managed Service for GitLab

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Nmap
• OpenVAS
• OWASP ZAP

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

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

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

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

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

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

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

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

ВведениеВведение

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

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

Шифрование в состоянии покоя (at rest)Шифрование в состоянии покоя (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 с ключом KMS4.1 В Yandex Object Storage включено шифрование данных at rest с ключом KMS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.7 Используется шифрование данных на уровне приложения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 Используется шифрование дисков и снимков виртуальных машин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)4.9 Ключи Key Management Service хранятся в аппаратном модуле безопасности (HSM)

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

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

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

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

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

4.10 Права на управление ключами в KMS выданы контролируемым пользователям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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВведениеВведение

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

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

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

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

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

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

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

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

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

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

Вы можете подробнее ознакомиться с 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.

5.3 Настроено реагирование на события Yandex Audit Trails5.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 Trails5.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 Выполняется сбор аудит логов с уровня ОС5.5 Выполняется сбор аудит логов с уровня ОС

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

• Osquery;
• Filebeat (ELK);
• Wazuh.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по защите приложения от роботной активностиРекомендации по защите приложения от роботной активности

8.1 Используется Yandex SmartCaptcha8.1 Используется Yandex SmartCaptcha

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

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

Инструкция по созданию капчи в Yandex SmartCaptcha.

Рекомендации по построению безопасного пайплайнаРекомендации по построению безопасного пайплайна

Yandex Cloud позволяет клиентам выстроить соответствие разрабатываемого ПО по всем уровням Supply-chain Levels for Software Artifacts (SLSA), при соблюдении инструкций в данном разделе. При использовании Yandex Managed Service for GitLab, клиент автоматически достигает соответствия до 2 уровня SLSA включительно.

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

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

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

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

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

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

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

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

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

8.4 Контейнерные образы, используемые в продакшн-среде, имеют последнюю дату сканирования не позднее недели8.4 Контейнерные образы, используемые в продакшн-среде, имеют последнюю дату сканирования не позднее недели

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

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 REGISTRY_ID in $(yc container registry list --folder-id $FOLDER_ID --format=json | jq -r '.[].id');
do for IMAGE_ID in $(yc container image list --registry-id $REGISTRY_ID --format=json | jq -r '.[].id';)
do LAST_SCAN_DATE=$(yc container image get-last-scan-result --image-id $IMAGE_ID --format=json 2>/dev/null | jq -r '.scanned_at');
[ ! -z "$LAST_SCAN_DATE" ] && [ $(date --date "$LAST_SCAN_DATE" +'%s') -lt $(date --date '7 days ago' +'%s') ] && echo "Regitry ID - $REGISTRY_ID, Image ID - $IMAGE_ID, Last scan date - $LAST_SCAN_DATE"
done;
done;
done;
done

8.5 При сборке артефактов применяются аттестации8.5 При сборке артефактов применяются аттестации

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

При использовании Managed Service for GitLab процесс применения аттестаций становится проще, потому что сервис имеет функцию генерации provenance attestation. SBOM может быть сгенерирован с использованием стороннего ПО syft.

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

Инструкция от Gitlab по аттестации артефактов.

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

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

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

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

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

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

8.7 Выполняется проверка подлинности артефактов при развертывании8.7 Выполняется проверка подлинности артефактов при развертывании

Чтобы обеспечить надежность, безопасность и совместимость приложений в Managed Service for Kubernetes, сервисе для автоматического масштабирования и развертывания приложений, необходимо свести к минимуму риск возникновения проблем, уязвимостей и сбоев во время развертывания и выполнения. Для этого используется подпись и проверка подписи в Managed Service for Kubernetes с помощью Cosign и Kyverno.

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

Инструкция по настройке подписи артефактов.

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

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

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

8.9 Используется профиль безопасности Yandex Smart Web Security8.9 Используется профиль безопасности Yandex Smart Web Security

Yandex Smart Web Security — сервис для защиты от DDoS-атак и ботов на прикладном уровне L7 сетевой модели OSI. Smart Web Security подключается к Yandex Application Load Balancer.

Функциональность сервиса сводится к проверке HTTP-запросов к защищаемому ресурсу на соответствие правилам, заданным в профиле безопасности. В зависимости от результатов проверки запросы пропускаются на защищаемый ресурс, блокируются или отправляются в сервис Yandex SmartCaptcha для дополнительной верификации.

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

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

8.10 Используется Web Application Firewall8.10 Используется Web Application Firewall

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

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

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

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

8.11 Используется Advanced Rate Limiter8.11 Используется Advanced Rate Limiter

Advanced Rate Limiter (ARL) — модуль для контроля и ограничения нагрузки на веб-приложения. Модуль позволяет установить лимит на количество HTTP-запросов за определенный промежуток времени. Все запросы сверх лимита будут блокироваться. Можно установить как единый лимит на весь трафик, так и настраивать отдельные лимиты для сегментирования запросов по определенным параметрам. Запросы для лимитов можно считать по одному или объединять в группы по заданному признаку.

Профиль ARL необходимо подключить к профилю безопасности Smart Web Security.

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

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

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

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

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

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

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

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

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

ВведениеВведение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.3 Нет доступа к API 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 настроены аутентификация и управление доступом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 используется безопасная конфигурация9.5 В Managed Service for Kubernetes используется безопасная конфигурация

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

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

9.6 Шифрование данных и управление секретами Managed Service for Kubernetes выполняются в формате ESO as a Service9.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.

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

• Инструкция по работе с External Secrets и Yandex Lockbox из описания проекта.
• Инструкция по работе с External Secrets и Yandex Lockbox из документации Yandex Cloud.

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

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

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

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

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

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

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

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

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

yc managed-kubernetes list-versions

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

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

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

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

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

Вы можете создавать резервные копии данных из групп узлов кластера Kubernetes с помощью инструмента Velero. Этот инструмент поддерживает работу с дисками Yandex Cloud с помощью CSI-драйвера Kubernetes, и позволяет создавать моментальные снимки дисков томов.

При работе с Velero, установленным вручную, вы можете использовать nfs, emptyDir, локальный или любой другой тип тома, в котором нет встроенной поддержки моментальных снимков. Чтобы использовать такой тип тома, задействуйте плагин restic при установке Velero. Velero, установленный из Cloud Marketplace, плагин restic не включает.

• Инструкция по резервному копированию кластера Kubernetes в Object Storage.

9.10 Используются чек-листы для безопасного создания и использования Docker-образа9.10 Используются чек-листы для безопасного создания и использования Docker-образа

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

• Dockerfile best practices.
• Kubernetes Security Checklist and Requirements.

Контролировать Dockerfile в процессе CI/CD можно с помощью утилиты Conftest.

При проверке минимальных образов или образов distroless (distroless images), в которых отсутствует shell, рекомендуется использовать ephemeral cointainers.

9.11 Используется политика безопасности Kubernetes9.11 Используется политика безопасности Kubernetes

Требования Pod Security Standards от Kubernetes позволяют предотвращать угрозы, связанные с объектами Kubernetes, такие как несанкционированный доступ к конфиденциальным данным или выполнение вредоносного кода.

Эти требования помогают обеспечить безопасность и надежность работы приложений в кластере Kubernetes. Для их реализации можно использовать встроенный инструмент Kubernetes Pod Security Admission Controller или открытое программное обеспечение, например, OPA Gatekeeper или Kyverno.

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

• Для контроля соответствия требованиям Pod Security Standarts также можно использовать следующие инструменты в рамках CI/CD:

  • Kyverno CLI
  • The gator CLI

• Инструмент Kubesec.

9.12 Настроен сбор аудитных логов для расследований инцидентов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.