Требования к шифрованию данных и управлению ключами и секретами

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

Yandex Cloud

Улучшена

Mikhail S.

Обновлена 20 октября 2025 г.

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

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

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

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

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

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

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

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

Compute Cloud (шифрование дисков ВМ);
Object Storage (шифрование бакетов);
Managed Service for Kubernetes (шифрование секретов).

4.1 Включено шифрование дисков в Yandex Compute Cloud

ID требования	Критичность
CRYPT17	Высокая

Поиск зашифрованных дисков ВМ:

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

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

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

Bash

export ORG_ID=<ID_организации>
CLOUDS=$(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id')

echo "Encrypted disks:"
for CLOUD_ID in $CLOUDS
  do
  FOLDERS=$(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id')
  for FOLDER_ID in $FOLDERS
  do
    DISKS=$(yc compute disk list --folder-id $FOLDER_ID --format=json | jq -r '.[] | select(.kms_key.key_id)' | jq -r '.id')

    if [[ -n "$DISKS" ]]; then
      for DISK in $DISKS
      do
        DISKDATA=$(yc compute disk get --id $DISK --folder-id $FOLDER_ID --format=json)
        VM_ID=$(echo $DISKDATA| jq -r '.instance_ids[]')

        VMDATA=""

        if [[ -n "$VM_ID" ]]; then
          VMDATA=$(yc compute instance get --id $VM_ID --folder-id $FOLDER_ID --format=json)
        fi

        echo "------------"
        echo "CLOUD_ID:" $CLOUD_ID
        echo "FOLDER_ID:" $FOLDER_ID
        echo "DISK_ID: "$(echo $DISKDATA | jq -r '.id')
        echo "DISK_NAME: "$(echo $DISKDATA | jq -r '.name')
        echo "DISK_TYPE: "$(echo $DISKDATA | jq -r '.type_id')
        echo "DISK_ZONE: "$(echo $DISKDATA | jq -r '.zone_id')
        echo "DISK_SIZE: "$(echo $DISKDATA | jq -r '.size')
        echo "DISK_KEY: "$(echo $DISKDATA | jq -r '.kms_key')

        if [[ -n "$VMDATA" ]]; then
          echo "VM_ID: "$(echo $VMDATA | jq -r '.id')
          echo "VM_NAME: "$(echo $VMDATA | jq -r '.name')
          echo "VM_STATUS: "$(echo $VMDATA | jq -r '.status')
        fi
        echo "------------"
      done
    fi
  done
done

PowerShell

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

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

$EncryptedVMs = @()
$VMDisks = @()

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

  foreach($Folder in $Folders) {
    $FolderDiskList = yc compute disk list --folder-id $Folder.id --format=json | ConvertFrom-Json | where{$_.kms_key}

    foreach($Disk in $FolderDiskList) {
      $VMData = $null

      if($Disk.instance_ids) {
        $VMData = yc compute instance get --id $Disk.instance_ids --folder-id $Folder.id --format=json | ConvertFrom-Json
      }

      $EncryptedVMs += $Disk | Select @{n="CloudID";e={$Cloud.CloudID}}, @{n="CloudName";e={$Cloud.CloudName}}, @{n="FolderID";e={$Folder.id}}, @{n="FolderName";e={$Folder.name}}, @{n="DiskID";e={$_.id}}, @{n="DiskName";e={$_.name}}, @{n="DiskType";e={$_.type_id}}, zone_id, @{n="DiskSize";e={$_.size/1GB}}, kms_key, @{n="VMID";e={$VMData.id}}, @{n="VMName";e={$VMData.name}}, @{n="VMStatus";e={$VMData.status}}
    }
  }
}

$EncryptedVMs

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

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

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

Если диск присоединен к ВМ и ВМ включена, рекомендуется выключить ее.
Создайте снимок диска.
Создайте из полученного снимка новый зашифрованный диск:
1. Нажмите кнопку Создать диск.
2. В открывшейся форме:
  1. В поле Имя задайте имя диска.
  2. В поле Зона доступности укажите нужную зону доступности.
  3. В поле Наполнение выберите Снимок и выберите созданный ранее снимок.
  4. В поле Тип задайте необходимый тип диска.
  5. В блоке Шифрование включите опцию Зашифрованный диск и выберите или создайте ключ шифрования KMS.
  6. Нажмите кнопку Создать диск.
После создания зашифрованного диска присоедините его к нужной ВМ вместо незашифрованного.

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

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

ID требования	Критичность
CRYPT1	Средняя

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

ID требования	Критичность
CRYPT2	Высокая

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

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

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

Выполните команду, указав имя нужного бакета:

yc storage bucket get-https <имя_бакета>

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

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

Включите доступ по HTTPS, если бакет используется для хостинга статического сайта.

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

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

ID требования	Критичность
CRYPT3	Высокая

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

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

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

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

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

Bash

export ORG_ID=<ID_организации>
CLOUDS=$(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id')
for CLOUD_ID in $CLOUDS
do
  FOLDERS=$(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id')
  for FOLDER_ID in $FOLDERS
  do
    yc application-load-balancer load-balancer list --folder-id $FOLDER_ID --format=json | jq -r '.[] | select(.listeners[0].tls | not)' | jq -r '.'
  done
done

PowerShell

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

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

$ALBWithoutTLS = @()

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

  foreach($Folder in $Folders) {
    $ALBWithoutTLS += yc application-load-balancer load-balancer list --folder-id $Folder.id --format=json | ConvertFrom-Json | where{!$_.listeners.tls}
  }
}

$ALBWithoutTLS

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

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

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

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

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

ID требования	Критичность
CRYPT4	Средняя

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

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

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

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

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

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

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

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

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

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

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

ID требования	Критичность
CRYPT5	Низкая

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

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

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

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

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for CDN in $(yc cdn resource list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc cdn resource get --id $CDN --format json | jq -r '. | select(.origin_protocol=="HTTPS" and .ssl_certificate.type=="CM" | not)' | jq -r '.id' 
done;
done;
done

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

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

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

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

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

4.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.

ID требования	Критичность
CRYPT7	Высокая

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

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

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).

ID требования	Критичность
CRYPT8	Средняя

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

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

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

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

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

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

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

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

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

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

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

ID требования	Критичность
CRYPT9	Информационная

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

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

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

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

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do yc kms symmetric-key list --folder-id=$FOLDER_ID --format json | jq -r '.[] | "KEY_ID " + .id + "FOLDER_ID " + .folder_id + "ALGORITM_ID " + .default_algorithm' 
done;
done

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

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

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

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

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

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

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

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

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

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

ID требования	Критичность
CRYPT10	Средняя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

export ORG_ID=<ID организации>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id'); 
do for KEY in $(yc kms symmetric-key list --folder-id=$FOLDER_ID --format=json | jq -r '.[].id'); \
do yc kms symmetric-key list-access-bindings --id $KEY --format json 
done;
done;
done

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

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

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

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

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

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

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

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

Примечание

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

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

ID требования	Критичность
CRYPT11	Высокая

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

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

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

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

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

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

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

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

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

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

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

ID требования	Критичность
CRYPT12	Высокая

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

ID требования	Критичность
CRYPT13	Высокая

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

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

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

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

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

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

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

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

Храните секреты в Lockbox.

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

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

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

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

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

ID требования	Критичность
CRYPT14	Средняя

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

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

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

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

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

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

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

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

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

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

ID требования	Критичность
CRYPT15	Высокая

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

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

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

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

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

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

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

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

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

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

ID требования	Критичность
CRYPT16	Информационная

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

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

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

Требования к шифрованию данных и управлению ключами и секретами

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

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

4.1 Включено шифрование дисков в Yandex Compute Cloud4.1 Включено шифрование дисков в Yandex Compute Cloud

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 Включено шифрование дисков в Yandex Compute Cloud

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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