Шифрование данных и управление ключами
Yandex Cloud предоставляет встроенные функции шифрования при использовании ряда сервисов. В зоне ответственности клиента находится включение шифрования в этих сервисах, а также самостоятельная реализация шифрования в других компонентах обработки критичных данных. Для шифрования данных и управления ключами шифрования предназначен сервис Yandex 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
Для защиты критичных данных в Compute Cloud рекомендуется использовать шифрование дисков и снимков дисков с помощью ключей Key Management Service.
Подробнее см. в разделе Шифрование в Compute Cloud.
Object Storage
Для защиты критичных данных в Object Storage рекомендуется использовать шифрование бакета на стороне сервера с помощью ключей Key Management Service (server-side encryption). Такое шифрование защищает от случайной или намеренной публикации содержимого бакета в интернете.
Подробнее см. в разделе Шифрование в Object Storage.
Managed Service for Kubernetes
Managed Service for Kubernetes предоставляет встроенный механизм шифрования секретов. Подробнее в разделе Секреты в Kubernetes ниже.
Шифрование в состоянии передачи (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-сертификатов для следующих сервисов:
- Yandex Object Storage
- Yandex Application Load Balancer
- Yandex Virtual Private Cloud (VPC)
- Yandex API Gateway
- Yandex Cloud CDN
Object Storage
Object Storage поддерживает безопасное подключение по протоколу HTTPS. Вы можете загрузить собственный сертификат безопасности, если к вашему сайту вObject Storage требуется доступ по протоколу HTTPS. Также доступна интеграция с сервисом Yandex Certificate Manager. См. инструкции в документации Object Storage:
При работе с сервисом Object Storage необходимо убедиться, что в клиенте отключена поддержка протоколов TLS ниже версии 1.2. При помощи политики (bucket policy) aws:securetransport необходимо проверить, что для бакета настроен запрет на работу без протокола TLS.
Application Load Balancer
Сервис Application Load Balancer поддерживает HTTPS-обработчик с загрузкой сертификата из Certificate Manager. См. описание настройки обработчика в документации Application Load Balancer.
Virtual Private Cloud (VPC)
Возможные варианты организации шифрованных каналов связи приведены в разделе Организация удаленного доступа и каналов связи.
Обратите внимание: сервис Yandex Cloud Interconnect не предоставляет встроенных механизмов шифрования. Необходимо защищать данные при передаче (encryption in transit) самостоятельно с помощью:
- установки в облаке VPN-шлюзов с функцией шифрования: например, виртуальных машин на основе образов Check Point из Yandex Cloud Marketplace;
- шифрования на уровне приложений;
- услуги ГОСТ VPN.
API Gateway
Yandex API Gateway поддерживает безопасное подключение по протоколу HTTPS. Вы можете загрузить собственный сертификат безопасности для доступа к вашему API-шлюзу по протоколу HTTPS.
Cloud CDN
Cloud CDN поддерживает безопасное подключение по протоколу HTTPS. Вы можете загрузить собственный сертификат безопасности для доступа к вашему CDN-ресурсу по протоколу HTTPS.
Самостоятельное шифрование
При использовании сервисов, которые не имеют встроенных функций шифрования, шифрование критичных данных является ответственностью клиента.
Managed Services for Databases
Если согласно требованиям регуляторов необходимо шифрование данных, следует шифровать их на уровне приложения перед записью в базы данных, например, с помощью KMS.
Yandex Message Queue
Если сервис Yandex Message Queue используется для передачи критичных данных или секретов (ключей шифрования, API-ключей и т. д.), то необходимо шифровать эти данные на уровне приложения перед отправкой в Message Queue, например, с помощью KMS. Для ключа KMS рекомендуется настроить период ротации больше либо равный максимальному времени обработки сообщения Message Queue.
Yandex Object Storage
Для шифрования данных на уровне приложения (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.
Управление ключами
Для шифрования данных и управления ключами рекомендуется использовать Yandex Key Management Service. KMS предназначен для защиты данных в инфраструктуре Yandex Cloud, а также подходит для шифрования и расшифровки любых ваших данных.
KMS использует схему шифрования AES-GCM. Вы можете выбрать длину ключа: 128, 192 или 256 — и настроить период ротации ключей в зависимости своих потребностей. Вы также можете создать ключ, все криптооперации с которым будут выполняться только внутри специализированного аппаратного устройства, см. раздел Аппаратный модуль безопасности (HSM).
Аутентификация и авторизация в KMS
Для доступа к сервису KMS необходимо использовать IAM-токен.
В случае автоматизации работы с KMS рекомендуется создать сервисный аккаунт и выполнять команды и скрипты от его имени. Если вы используете виртуальные машины, получите IAM-токен для сервисного аккаунта через механизм назначения сервисного аккаунта виртуальной машине. Другие способы получения IAM-токена для сервисного аккаунта приведены в разделе Получение IAM-токена для сервисного аккаунта документации IAM.
Рекомендуется выдавать пользователям и сервисным аккаунтам гранулярные доступы на конкретные ключи сервиса KMS, см. раздел Управление доступом в Key Management Service документации KMS.
Подробнее о мерах безопасности при управлении доступом читайте в разделе Аутентификация и управление доступом.
Ротация ключей
Для повышения безопасности инфраструктуры рекомендуется разделить ключи шифрования на две группы:
- Ключи для сервисов, которые обрабатывают критичные данные, но не хранят их. Например, Yandex Message Queue, Yandex Cloud Functions.
- Ключи для сервисов, которые хранят критичные данные. Например, Managed Services for Databases.
Для первой группы ключей рекомендуется настроить автоматическую ротацию ключей с периодом ротации чуть больше, чем срок обработки данных в этих сервисах. По истечении периода ротации старые версии должны быть удалены. При автоматической ротации и удалении старых версий ключей ранее обработанные данные не смогут быть восстановлены и расшифрованы.
Для сервисов хранения данных рекомендуется использовать либо ручные процедуры ротации, либо автоматическую ротацию ключей в зависимости от внутренних процедур обработки критичных данных.
Безопасным значением для AES-GCM является шифрование 4 294 967 296 (= 232) блоков. После достижения этого количества шифрованных блоков необходимо создать новую версию ключа шифрования данных. Подробнее про режим работы AES-GCM см. в материалах NIST
Внимание
Удаление какой-либо версии ключа равносильно уничтожению всех данных, зашифрованных с ее помощью. Ключ можно защитить от удаления с помощью установки параметра deletionProtection, однако этот параметр не защищает от удаления отдельных версий.
Подробнее о ротации ключей см. в разделе Версия ключа документации KMS.
Управление секретами
Критичные данные и секреты для доступа к данным (токены аутентификации, API-ключи, ключи шифрования и т. п.) не следует использовать в открытом виде в коде, в названиях и описаниях объектов облака, в метаданных виртуальных машин и т. д. Вместо этого используйте сервисы для хранения секретов, такие как Yandex Lockbox или HashiCorp Vault.
Yandex Lockbox
Сервис Yandex Lockbox обеспечивает безопасное хранение секретов: секреты хранятся только в зашифрованном виде, шифрование выполняется с помощью KMS. Для разграничения доступа к секретам используйте сервисные роли.
Инструкции по работе с сервисом см. в документации Lockbox.
HashiCorp Vault
Vault
Для хранения секретов с помощью Vault можно использовать виртуальную машину на основе образа из Yandex Cloud Marketplace с предустановленной сборкой HashiCorp Vault и поддержкой Auto Unseal. Инструкция по настройке Auto Unseal приведена в разделе Auto Unseal в Hashicorp Vault документации KMS.
Секреты в Kubernetes
Для хранения секретов, таких как пароли, OAuth-токены, SSH-ключи, используйте один из способов:
-
Механизм секретов Kubernetes
.По умолчанию секреты хранятся в etcd в незашифрованном виде, однако Managed Service for Kubernetes предоставляет возможность шифрования секретов с помощью KMS. Чтобы включить шифрование секретов, укажите ключ KMS при создании кластера Kubernetes. Ключ нельзя добавить при изменении кластера. Подробнее в разделе Шифрование секретов в Yandex Managed Service for Kubernetes документации KMS.
-
Yandex Lockbox.
См. инструкцию в разделе Синхронизация с секретами Yandex Managed Service for Kubernetes документации Yandex Lockbox.
-
HashiCorp Vault с поддержкой KMS из Yandex Cloud Marketplace.
Передача секретов в ВМ с помощью Terraform и KMS
KMS предоставляет возможность шифрования секретов, используемых в конфигурации Terraform, в частности, для передачи секретов на виртуальную машину в зашифрованном виде. См. инструкцию в разделе Шифрование секретов в Hashicorp Terraform документации KMS. Передача секретов через переменные окружения в открытом виде небезопасна, поскольку они отображаются в свойствах ВМ.
Другие рекомендации по безопасному использованию Terraform см. в разделе Безопасная конфигурация: Terraform.