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

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

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

Введение

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

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

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

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

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

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

  • Object Storage;
  • Managed Service for Kubernetes.

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    yc organization-manager organization list

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

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

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

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

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

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

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

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

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

    yc organization-manager organization list

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

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

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

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

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

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

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

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

    yc organization-manager organization list

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    yc organization-manager organization list

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

  3. Если алгоритм шифрования содержит 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.
  1. В консоли управления выберите облако или каталог, в которых необходимо проверить права на ключ.
  2. Перейдите на вкладку Права доступа.
  3. Убедитесь, что роли admin, editor, kms.admin, kms.editor, kms.keys.encrypterDecrypter имеют только контролируемые пользователи.
  4. Проверить права доступа к самим ключам возможно только через CLI.

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

    yc organization-manager organization list

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

    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")'

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

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

    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

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

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

    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

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

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

    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 (= 232) блоков. После достижения этого количества шифрованных блоков необходимо создать новую версию ключа шифрования данных. Подробнее про режим работы AES-GCM см. в материалах NIST.

Примечание

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

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

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

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

    yc organization-manager organization list

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

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

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

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

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

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

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

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

    yc organization-manager organization list

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

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

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

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

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

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

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.

Примечание

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

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

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

    yc organization-manager organization list

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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