Модели шифрования данных

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

Существует три сценария для шифрования на стороне сервера:

  • Шифрование на стороне сервера с помощью управляемых службой ключей

    • поставщики ресурсов Azure выполняют операции шифрования и расшифровки;
    • ключами управляет Майкрософт;
    • все возможности облака.
  • Шифрование на стороне сервера с помощью управляемых пользователем ключей в Azure Key Vault:

    • поставщики ресурсов Azure выполняют операции шифрования и расшифровки;
    • пользователь управляет ключами через Azure Key Vault;
    • все возможности облака.
  • Шифрование на стороне сервера с использованием администрируемых пользователем ключей на управляемом пользователем оборудовании:

    • поставщики ресурсов Azure выполняют операции шифрования и расшифровки;
    • пользователь администрирует ключи на управляемом оборудовании;
    • все возможности облака.

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

Server

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

Для шифрования на стороне клиента учтите следующее:

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

Поддерживаемые модели шифрования в Azure разделены на две основные группы: "Шифрование на стороне клиента" и "Шифрование на стороне сервера", как упоминалось ранее. Независимо от используемой модели шифрования неактивных данных службы Azure всегда рекомендуют использовать безопасный канал транспорта, например TLS или HTTPS. Таким образом, шифрование на транспортном уровне должно определяться транспортным протоколом и не должно быть основным фактором при определении используемой модели шифрования неактивных данных.

Модель шифрования клиентом

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

Client

Шифрование на стороне сервера с помощью управляемых службой ключей

Для многих пользователей существенным требованием является гарантия шифрования неактивных данных. Шифрование на стороне сервера с помощью управляемых службой ключей позволяет реализовать эту модель, давая пользователям возможность помечать конкретный ресурс (учетную запись хранения, базу данных SQL и т. д.) для шифрования и передает все аспекты управления ключами, например выдачу, смену и резервное копирование ключей, корпорации Майкрософт. Большинство служб Azure, которые поддерживают шифрование в состоянии хранения, обычно поддерживают эту модель передачи задач управления ключами шифрования в Azure. Поставщик ресурсов Azure создает ключи и помещает их в надежное хранилище, извлекая их при необходимости. Это означает, что служба имеет полный доступ к ключам и полностью контролирует жизненный цикл учетных данных.

managed

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

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

Доступ к ключам

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

Преимущества

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

Недостатки

  • Пользователь не управляет ключами шифрования (спецификацией, жизненным циклом, отзывом ключей и т. д.).
  • Отсутствует возможность отделить управление ключами от общей модели управления для службы.

Шифрование на стороне сервера с помощью управляемых пользователем ключей в Azure Key Vault:

Для сценариев, в которых требуется шифровать неактивные данные и управлять ключами шифрования, можно использовать шифрование на стороне сервера с помощью управляемых пользователем ключей в хранилище ключей. Некоторые службы могут хранить корневой ключ шифрования ключей в Azure Key Vault и хранить зашифрованный ключ шифрования данных во внутреннем расположении рядом с данными. В таком сценарии пользователи могут переносить свои собственные ключи (BYOK) в хранилище ключей или создать ключи и использовать их для шифрования нужных ресурсов. Когда поставщик ресурсов выполняет операции шифрования и расшифровки, он использует настроенный ключ шифрования ключей в качестве корневого ключа для всех операций шифрования.

Потеря ключей шифрования ключей означает потерю данных. По этой причине ключи не следует удалять. Необходимо создавать резервные копии ключей при создании или смене. В любом хранилище, в котором находятся ключи шифрования ключей, должна быть включена защита от обратимого удаления и очистки для защиты от случайного или злонамеренного удаления криптографических ключей. Вместо удаления ключа рекомендуется присвоить параметру enabled в ключе шифрования ключей значение false. Используйте элементы управления для отмены доступа к отдельным пользователям или службам в Azure Key Vault или управляемом модуле HSM.

Доступ к ключам

В модели шифрования на стороне сервера с хранением в Azure Key Vault ключей, управляемых пользователем, служба при необходимости получает доступ к ключам для шифрования и расшифровки. Ключи для шифрования неактивных данных становятся доступными для службы благодаря политике управления доступом. Эта политика предоставляет службе доступ на основе удостоверения для получения ключа. Службу Azure, запущенную от имени связанной подписки, можно настроить с помощью удостоверения в рамках этой подписки. Служба может выполнять проверку подлинности Azure Active Directory и получать токен проверки подлинности, идентифицируя себя как службу, которая действует от имени подписки. Затем этот токен может быть предоставлен хранилищу ключей для получения ключа, доступ к которому был получен.

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

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

Примечание

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

Преимущества

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

Недостатки

  • Пользователь полностью отвечает за управление доступом к ключам.
  • Пользователь полностью отвечает за управление жизненным циклом ключей.
  • Дополнительные издержки в процессе установки и конфигурации

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

Некоторые службы Azure допускают использование модели управления с размещением собственного ключа (HYOK). Этот режим управления рекомендуется для использования в сценариях, в которых необходимо шифровать данные в состоянии хранения и управлять ключами в собственном репозитории без участия корпорации Майкрософт. В этой модели службе необходимо получить ключ с внешнего сайта. Что в результате оказывает влияние на производительность и гарантии доступности, а конфигурация усложняется. Кроме того, так как служба имеет доступ к ключу шифрования данных во время операции шифрования и расшифровки, общие гарантии безопасности этой модели аналогичны модели, в которой ключами управляют пользователи в Azure Key Vault. В результате эта модель не подходит для большинства организаций, если они не имеют конкретных требований к управлению ключами. Вследствие этих ограничений большинство служб Azure не поддерживают шифрование на стороне сервера с использованием ключей, управляемых сервером, на оборудовании, контролируемом заказчиком.

Доступ к ключам

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

Преимущества

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

Недостатки

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

Поддержка служб

Службы Azure, поддерживающие все модели шифрования:

продукт, функция или служба На стороне сервера с помощью управляемого службой ключа На стороне сервера с использованием управляемого клиентом ключа На стороне клиента с использованием управляемого клиентом ключа
ИИ и Машинное обучение
Когнитивный поиск Azure Да Да -
Azure Cognitive Services Да Да -
Машинное обучение Azure Да Да -
Content Moderator Да Да -
Распознавание лиц Да Да -
Распознавание речи Да Да -
Персонализатор Да Да -
QnA Maker Да Да -
Службы "Речь" Да Да -
Перевод текстов Да Да -
Power BI Да Да, 4096-разрядный RSA -
Аналитика
Azure Stream Analytics Да Да**, включая управляемый HSM -
Центры событий Да Да -
Функции Да Да -
Службы Azure Analysis Services Да - -
Каталог данных Azure Да - -
Azure HDInsight Да Все -
Аналитика приложения Azure Monitor Да Да -
Azure Monitor и Log Analytics Да Да -
Azure Data Explorer Да Да -
Фабрика данных Azure Да Да, включая управляемый HSM -
Хранилище озера данных Azure Да Да, 2048-разрядный RSA -
Контейнеры
Служба Azure Kubernetes Да Да, включая управляемый HSM -
Экземпляры контейнеров Да Да -
Реестр контейнеров Да Да -
Compute
Виртуальные машины Да Да, включая управляемый HSM -
Масштабируемый набор виртуальных машин Да Да, включая управляемый HSM -
SAP HANA Да Да -
Служба приложений Да Да**, включая управляемый HSM -
Служба автоматизации Да Да -
Функции Azure Да Да**, включая управляемый HSM -
Портал Azure Да Да**, включая управляемый HSM -
Logic Apps Да Да -
Управляемые приложения Azure Да Да**, включая управляемый HSM -
Служебная шина Да Да -
Site Recovery Да Да -
Базы данных
SQL Server на виртуальных машинах Да Да Да
База данных SQL Azure Да Да, 3072-разрядный RSA, включая управляемый HSM Да
Управляемый экземпляр SQL Azure Да Да, 3072-разрядный RSA, включая управляемый HSM Да
База данных Azure SQL для MariaDB Да - -
База данных Azure SQL для MySQL Да Да -
База данных Azure SQL для PostgreSQL Да Да -
Azure Synapse Analytics Да Да, 3072-разрядный RSA, включая управляемый HSM -
SQL Server Stretch Database Да Да, 3072-разрядный RSA Да
Хранилище таблиц Да Да Да
Azure Cosmos DB Да (подробнее) Да (подробнее) -
Azure Databricks Да Да -
Azure Database Migration Service Да Недоступно* -
Удостоверение
Azure Active Directory Да - -
Доменные службы Azure Active Directory Да Да -
Интеграция
Служебная шина Да Да Да
Сетка событий Azure Да - -
Управление API Да - -
Службы Интернета вещей
Центр Интернета вещей Да Да Да
Подготовка устройств к добавлению в центр Интернета вещей Да Да -
Управление
Управление Azure для Grafana Да - Н/Д
Azure Site Recovery Да - -
Служба "Миграция Azure" Да Да -
Носитель
Службы мультимедиа Да Да Да
Безопасность
Microsoft Defender для Интернета вещей Да Да -
Microsoft Sentinel Да Да -
Память
Хранилище BLOB-объектов Да Да, включая управляемый HSM Да
Хранилище BLOB-объектов класса "Премиум" Да Да, включая управляемый HSM Да
Хранилище дисков Да Да, включая управляемый HSM -
Хранилище дисков категории "Ультра" Да Да, включая управляемый HSM -
Управляемое хранилище дисков Да Да, включая управляемый HSM -
Хранилище файлов Да Да, включая управляемый HSM -
Хранилище файлов класса "Премиум" Да Да, включая управляемый HSM -
Синхронизация файлов Azure Да Да, включая управляемый HSM -
Хранилище очередей Да Да, включая управляемый HSM Да
Data Lake Storage 2-го поколения Да Да, включая управляемый HSM Да
Avere vFXT Да - -
Кэш Azure для Redis Да Недоступно* -
Azure NetApp Files Да Да -
Архивное хранилище Да Да -
StorSimple Да Да Да
Azure Backup Да Да Да
Data Box Да - Да
Data Box Edge Да Да -

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

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

Дальнейшие действия