Модели шифрования данных
Знакомство с различными моделями шифрования, их преимуществами и недостатками необходимо для понимания реализации шифрования неактивных данных в Azure различными поставщиками ресурсов. Эти определения являются общими для всех поставщиков ресурсов в Azure для обеспечения общей среды и таксономии.
Существует три сценария для шифрования на стороне сервера:
Шифрование на стороне сервера с помощью управляемых службой ключей
- поставщики ресурсов Azure выполняют операции шифрования и расшифровки;
- ключами управляет Майкрософт;
- все возможности облака.
Шифрование на стороне сервера с помощью управляемых пользователем ключей в Azure Key Vault
- поставщики ресурсов Azure выполняют операции шифрования и расшифровки;
- пользователь управляет ключами через Azure Key Vault;
- все возможности облака.
Шифрование на стороне сервера с использованием администрируемых пользователем ключей на управляемом пользователем оборудовании:
- поставщики ресурсов Azure выполняют операции шифрования и расшифровки;
- пользователь администрирует ключи на управляемом оборудовании;
- все возможности облака.
Модели шифрования на стороне сервера относятся к шифрованию, выполняемому службой Azure. В этой модели поставщик ресурсов выполняет операции шифрования и расшифровки. Например, служба хранилища Azure может получать данные посредством простых текстовых операций, а затем выполнять внутренние шифрование и расшифровку. Поставщик ресурсов может использовать ключи шифрования, управляемые Майкрософт или пользователем, в зависимости от конфигурации.
Каждая из моделей шифрования неактивных данных на стороне сервера подразумевает отличные характеристики управления ключами, в частности то, где и как создаются и хранятся ключи шифрования, а также модели доступа и процедуры смены ключей.
Для шифрования на стороне клиента учтите следующее:
- расшифрованные данные недоступны службам Azure;
- управление ключами и их хранение доступно в локальной среде или других безопасных хранилищах. Ключи недоступны для служб Azure
- возможности облака ограничены.
Поддерживаемые модели шифрования в Azure разделены на две основные группы: "Шифрование на стороне клиента" и "Шифрование на стороне сервера", как упоминалось ранее. Независимо от используемой модели шифрования неактивных данных службы Azure всегда рекомендуют использовать безопасный канал транспорта, например TLS или HTTPS. Таким образом, шифрование на транспортном уровне должно определяться транспортным протоколом и не должно быть основным фактором при определении используемой модели шифрования неактивных данных.
Модель шифрования клиентом
Модель шифрования клиентом — это шифрование, выполняемое службой или вызывающим приложением за пределами поставщика ресурсов или Azure. Это шифрование можно выполнить с помощью приложения службы в Azure или приложения, работающего в центре обработки данных пользователя. В любом случае при использовании этой модели шифрования поставщик ресурсов Azure принимает зашифрованный большой двоичный объект данных без возможности расшифровки этих данных каким-либо образом, а также без доступа к ключам шифрования. В этой модели ключами управляют вызывающие приложение или служба. Этот процесс является непрозрачным для службы Azure.
Шифрование на стороне сервера с помощью управляемых службой ключей
Для многих пользователей существенным требованием является гарантия шифрования неактивных данных. Шифрование на стороне сервера с помощью управляемых службой ключей позволяет реализовать эту модель, давая пользователям возможность помечать конкретный ресурс (учетную запись хранения, базу данных SQL и т. д.) для шифрования и передает все аспекты управления ключами, например выдачу, смену и резервное копирование ключей, корпорации Майкрософт. Большинство служб Azure, которые поддерживают шифрование в состоянии хранения, обычно поддерживают эту модель передачи задач управления ключами шифрования в Azure. Поставщик ресурсов Azure создает ключи и помещает их в надежное хранилище, извлекая их при необходимости. Это означает, что служба имеет полный доступ к ключам и полностью контролирует жизненный цикл учетных данных.
Таким образом, шифрование на стороне сервера с помощью управляемых службой ключей быстро выполняет шифрование неактивных данных с низкими издержками для пользователя. Откройте целевую подписку и поставщика ресурсов на портале Azure и установите флажок, указывающий, что данные требуется зашифровать. В некоторых диспетчерах ресурсов шифрование на стороне сервера с помощью управляемых службой ключей включено по умолчанию.
Шифрование на стороне сервера с помощью ключей, управляемых Майкрософт, подразумевает, что служба имеет полный доступ к хранению ключей и управлению ими. Хотя некоторые пользователи хотят управлять ключами, так как они считают, что они получат больше безопасности, при оценке такой модели следует учитывать затраты и риски, связанные с использованием пользовательского хранилища ключей. Во многих случаях организация может решить, что нехватка ресурсов или риски, связанные с локальным решением, превышают риски облачного управления ключами шифрования неактивных данных. Однако этой модели может быть недостаточно для организаций, у которых есть требования к управлению созданием или жизненным циклом ключей шифрования или к тому, чтобы ключами шифрования службы управляли другие специалисты, не те, кто управляет службой (т. е. использование для службы модели управления с разделением управления ключами и общего управления).
Доступ к ключам
При использовании шифрования на стороне сервера с ключами, управляемыми службой, созданием и хранением ключей, а также доступом к ним службами управляет служба. Как правило, основные поставщики ресурсов Azure хранят ключи шифрования данных в хранилище рядом с данными для быстрого доступа, в то время как ключи шифрования ключей хранятся в защищенном внутреннем хранилище.
Преимущества
- Простая настройка
- Корпорация Майкрософт управляет сменой, резервным копированием и избыточностью ключей.
- Пользователь не несет затраты, связанные с реализацией, и для него нет риска использования пользовательской схемы управления ключами.
Недостатки
- Пользователь не управляет ключами шифрования (спецификацией, жизненным циклом, отзывом ключей и т. д.).
- Отсутствует возможность отделить управление ключами от общей модели управления для службы.
Шифрование на стороне сервера с помощью управляемых пользователем ключей в Azure Key Vault
Для сценариев, в которых требуется шифровать неактивные данные и управлять ключами шифрования, можно использовать шифрование на стороне сервера с помощью управляемых пользователем ключей в хранилище ключей. Некоторые службы могут хранить корневой ключ шифрования ключей в Azure Key Vault и хранить зашифрованный ключ шифрования данных во внутреннем расположении рядом с данными. В таком сценарии пользователи могут переносить свои собственные ключи (BYOK) в хранилище ключей или создать ключи и использовать их для шифрования нужных ресурсов. Когда поставщик ресурсов выполняет операции шифрования и расшифровки, он использует настроенный ключ шифрования ключей в качестве корневого ключа для всех операций шифрования.
Потеря ключей шифрования ключей означает потерю данных. По этой причине ключи не следует удалять. Необходимо создавать резервные копии ключей при создании или смене. В любом хранилище, в котором находятся ключи шифрования ключей, должна быть включена защита от обратимого удаления и очистки для защиты от случайного или злонамеренного удаления криптографических ключей. Вместо удаления ключа рекомендуется присвоить параметру enabled в ключе шифрования ключей значение false. Используйте элементы управления для отмены доступа к отдельным пользователям или службам в Azure Key Vault или управляемом модуле HSM.
Доступ к ключам
В модели шифрования на стороне сервера с хранением в Azure Key Vault ключей, управляемых пользователем, служба при необходимости получает доступ к ключам для шифрования и расшифровки. Ключи для шифрования неактивных данных становятся доступными для службы благодаря политике управления доступом. Эта политика предоставляет службе доступ на основе удостоверения для получения ключа. Службу Azure, запущенную от имени связанной подписки, можно настроить с помощью удостоверения в рамках этой подписки. Служба может выполнять проверку подлинности Microsoft Entra и получать маркер проверки подлинности, определяющий себя как эта служба, выступающая от имени подписки. Затем этот токен может быть предоставлен хранилищу ключей для получения ключа, доступ к которому был получен.
Для операций с использованием ключей шифрования удостоверению службы можно предоставить доступ к любой из следующих операций: расшифровка, шифрование, упаковка, распаковка, проверка, подписывание, получение, перечисление, обновление, создание, импорт, удаление, резервное копирование и восстановление.
Чтобы получить ключ для шифрования или расшифровки неактивных данных, удостоверение службы, запущенное экземпляром службы диспетчера ресурсов, должно иметь ключ распаковки (чтобы получить ключ для расшифровки) и ключ упаковки (чтобы вставить ключ в хранилище ключей при создании нового ключа).
Примечание.
Дополнительные сведения об авторизации в хранилище ключей см. в статье Защита хранилища ключей.
Преимущества
- Полный контроль над используемыми ключами – управление ключами шифрования производится в хранилище ключей клиента под его контролем.
- Возможность шифрования нескольких служб с помощью главного ключа.
- Возможность отделить управление ключами от общей модели управления для службы.
- Возможность определить службу и расположение ключа в нескольких регионах.
Недостатки
- Пользователь полностью отвечает за управление доступом к ключам.
- Пользователь полностью отвечает за управление жизненным циклом ключей.
- Дополнительные издержки в процессе установки и конфигурации.
Шифрование на стороне сервера с использованием администрируемых пользователем ключей на управляемом пользователем оборудовании
Некоторые службы Azure допускают использование модели управления с размещением собственного ключа (HYOK). Этот режим управления рекомендуется для использования в сценариях, в которых необходимо шифровать данные в состоянии хранения и управлять ключами в собственном репозитории без участия корпорации Майкрософт. В этой модели служба должна использовать ключ из внешнего сайта для расшифровки ключа шифрования данных (DEK). Что в результате оказывает влияние на производительность и гарантии доступности, а конфигурация усложняется. Кроме того, так как служба имеет доступ к ключу шифрования данных во время операции шифрования и расшифровки, общие гарантии безопасности этой модели аналогичны модели, в которой ключами управляют пользователи в Azure Key Vault. В результате эта модель не подходит для большинства организаций, если они не имеют конкретных требований к управлению ключами. Из-за этих ограничений большинство служб Azure не поддерживают шифрование на стороне сервера с помощью ключей, управляемых клиентом, в оборудовании, управляемом клиентом. Один из двух ключей в шифровании двойных ключей следует этой модели.
Доступ к ключам
При использовании шифрования на стороне сервера с помощью ключей, управляемых клиентом, в оборудовании, управляемом клиентом, ключи шифрования ключей сохраняются в системе, настроенной клиентом. Службы Azure, которые поддерживают эту модель, предоставляют средства для создания безопасного подключения к хранилищу ключей, предоставленному пользователем.
Преимущества
- Полный контроль над корневым ключом. Ключи шифрования управляются в хранилище пользователя.
- Возможность шифрования нескольких служб с помощью главного ключа.
- Возможность отделить управление ключами от общей модели управления для службы.
- Возможность определить службу и расположение ключа в нескольких регионах.
Недостатки
- Полная ответственность за хранение ключей, безопасность, производительность и доступность.
- Полная ответственность за управление доступом к ключам.
- Полная ответственность за управление жизненным циклом ключей.
- Значительные расходы на установку, настройку и текущее обслуживание.
- Повышенная зависимость от доступности сети между центрами обработки данных Azure и центром обработки данных пользователя.
Поддержка служб
Службы Azure, поддерживающие все модели шифрования:
| продукт, функция или служба | На стороне сервера с помощью управляемого службой ключа | На стороне сервера с использованием управляемого клиентом ключа | На стороне клиента с использованием управляемого клиентом ключа |
|---|---|---|---|
| ИИ и Машинное обучение | |||
| Поиск по искусственному интеллекту Azure | Да | Да | - |
| Службы искусственного интеллекта Azure | Да | Да, включая управляемый HSM | - |
| Машинное обучение Azure | Да | Да | - |
| Content Moderator | Да | Да, включая управляемый HSM | - |
| Распознавание лиц | Да | Да, включая управляемый HSM | - |
| Распознавание речи | Да | Да, включая управляемый HSM | - |
| Azure OpenAI | Да | Да, включая управляемый HSM | - |
| Персонализатор | Да | Да, включая управляемый HSM | - |
| QnA Maker | Да | Да, включая управляемый HSM | - |
| Службы речи | Да | Да, включая управляемый HSM | - |
| Перевод текстов | Да | Да, включая управляемый HSM | - |
| Power BI | Да | Да, 4096-разрядный RSA | - |
| Аналитика | |||
| Azure Stream Analytics | Да | Да**, включая управляемый HSM | - |
| Event Hubs | Да | Да | - |
| Функции | Да | Да | - |
| Azure Analysis Services | Да | - | - |
| Каталог данных Azure | Да | - | - |
| Azure HDInsight | Да | Да | - |
| Azure Monitor Application Insights | Да | Да | - |
| Log Analytics в Azure Monitor | Да | Да, включая управляемый HSM | - |
| Azure Data Explorer | Да | Да | - |
| Azure Data Factory | Да | Да, включая управляемый HSM | - |
| Azure Data Lake Store | Да | Да, 2048-разрядный RSA | - |
| Контейнеры | |||
| Служба Azure Kubernetes | Да | Да, включая управляемый HSM | - |
| Экземпляры контейнеров | Да | Да | - |
| Реестр контейнеров | Да | Да | - |
| Среда выполнения приложений | |||
| Виртуальные машины | Да | Да, включая управляемый HSM | - |
| Масштабируемый набор виртуальных машин | Да | Да, включая управляемый HSM | - |
| SAP HANA | Да | Да | - |
| Служба приложений | Да | Да**, включая управляемый HSM | - |
| Автоматизация | Да | Да | - |
| Функции Azure | Да | Да**, включая управляемый HSM | - |
| Портал Azure | Да | Да**, включая управляемый HSM | - |
| Решение Azure VMware | Да | Да, включая управляемый HSM | - |
| Logic Apps | Да | Да | - |
| Управляемые приложения Azure | Да | Да**, включая управляемый HSM | - |
| Cлужебная шина | Да | Да | - |
| Site Recovery | Да | Да | - |
| Базы данных | |||
| SQL Server на виртуальных машинах | Да | Да | Да |
| База данных SQL Azure | Да | Да, 3072-разрядный RSA, включая управляемый HSM | Да |
| Управляемый экземпляр SQL Azure | Да | Да, 3072-разрядный RSA, включая управляемый HSM | Да |
| База данных Azure SQL для MariaDB | Да | - | - |
| База данных SQL Azure для MySQL | Да | Да | - |
| База данных Azure SQL для PostgreSQL | Да | Да, включая управляемый HSM | - |
| Azure Synapse Analytics (только выделенный пул SQL (ранее — хранилище данных SQL) | Да | Да, 3072-разрядный RSA, включая управляемый HSM | - |
| SQL Server Stretch Database | Да | Да, 3072-разрядный RSA | Да |
| Хранилище таблиц | Да | Да | Да |
| Azure Cosmos DB | Да (подробнее) | Да, включая управляемый HSM (дополнительные сведения и дополнительные сведения) | - |
| Azure Databricks | Да | Да, включая управляемый HSM | - |
| Azure Database Migration Service | Да | Н/Д* | - |
| Identity | |||
| Microsoft Entra ID | Да | - | - |
| Доменные службы Microsoft Entra | Да | Да | - |
| Интеграция | |||
| Cлужебная шина | Да | Да | - |
| Сетка событий | Да | - | - |
| Управление API | Да | - | - |
| Службы Интернета вещей | |||
| Центр IoT | Да | Да | Да |
| Подготовка устройств к добавлению в центр Интернета вещей | Да | Да | - |
| Управление | |||
| Управление Azure для Grafana | Да | - | Н/П |
| Azure Site Recovery | Да | - | - |
| Служба "Миграция Azure" | Да | Да | - |
| Медиа | |||
| Службы мультимедиа | Да | Да | Да |
| Безопасность | |||
| Microsoft Defender для Интернета вещей | Да | Да | - |
| Microsoft Sentinel | Да | Да, включая управляемый HSM | - |
| Память | |||
| Хранилище BLOB-объектов | Да | Да, включая управляемый HSM | Да |
| Хранилище BLOB-объектов ценовой категории "Премиум" | Да | Да, включая управляемый HSM | Да |
| Хранилище дисков | Да | Да, включая управляемый HSM | - |
| Хранилище дисков (цен. категория "Ультра") | Да | Да, включая управляемый HSM | - |
| Хранилище управляемых дисков | Да | Да, включая управляемый HSM | - |
| Хранилище файлов | Да | Да, включая управляемый HSM | - |
| Хранилище файлов класса "Премиум" | Да | Да, включая управляемый HSM | - |
| Синхронизация файлов | Да | Да, включая управляемый HSM | - |
| Хранилище очередей | Да | Да, включая управляемый HSM | Да |
| Data Lake Storage 2-го поколения | Да | Да, включая управляемый HSM | Да |
| Avere vFXT | Да | - | - |
| Кэш Azure для Redis | Да | Н/Д* | - |
| Azure NetApp Files | Да | Да | Да |
| Архивное хранилище | Да | Да | - |
| StorSimple | Да | Да | Да |
| Azure Backup | Да | Да, включая управляемый HSM | Да |
| Data Box | Да | - | Да |
| Data Box Edge | Да | Да | - |
| Другое | |||
| Azure Data Manager для предварительной версии энергетики | Да | - | Да |
* Эта служба не сохраняет данные. Временные кэши, если они имеются, зашифрованы с помощью ключа Майкрософт.
** Эта служба поддерживает хранение данных в собственном хранилище Key Vault, учетной записи хранения или другой службе хранения данных, которая уже поддерживает шифрование на стороне сервера с ключом, управляемым клиентом.
Следующие шаги
- Сведения о том, как используется шифрование в Azure.
- Сведения о том, как в Azure используется двойное шифрование для устранения угроз, возникающих при шифровании данных.