Модели шифрования данных
Знакомство с различными моделями шифрования, их преимуществами и недостатками необходимо для понимания реализации шифрования неактивных данных в 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 и Управляемом HSM Azure
Для сценариев, в которых требуется шифровать неактивные данные и управлять ключами шифрования, можно использовать шифрование на стороне сервера с помощью управляемых пользователем ключей в хранилище ключей. Некоторые службы могут хранить только корневой ключ шифрования ключей в Azure Key Vault и хранить зашифрованный ключ шифрования данных в внутреннем расположении ближе к данным. В таком сценарии пользователи могут переносить свои собственные ключи (BYOK) в хранилище ключей или создать ключи и использовать их для шифрования нужных ресурсов. Когда поставщик ресурсов выполняет операции шифрования и расшифровки, он использует настроенный ключ шифрования ключей в качестве корневого ключа для всех операций шифрования.
Потеря ключей шифрования ключей означает потерю данных. По этой причине ключи не следует удалять. Необходимо создавать резервные копии ключей при создании или смене. В любом хранилище, в котором находятся ключи шифрования ключей, должна быть включена защита от обратимого удаления и очистки для защиты от случайного или злонамеренного удаления криптографических ключей. Вместо удаления ключа рекомендуется присвоить параметру enabled в ключе шифрования ключей значение false. Используйте элементы управления для отмены доступа к отдельным пользователям или службам в Azure Key Vault или управляемом модуле HSM.
Примечание.
Список служб, поддерживающих управляемые клиентом ключи в Azure Key Vault и Управляемом HSM Azure, см . в службах, поддерживающих cmKs в Azure Key Vault и Управляемом HSM Azure.
Доступ к ключам
В модели шифрования на стороне сервера с хранением в Azure Key Vault ключей, управляемых пользователем, служба при необходимости получает доступ к ключам для шифрования и расшифровки. Ключи шифрования неактивных данных становятся доступными для службы с помощью политики управления доступом. Эта политика предоставляет службе доступ на основе удостоверения для получения ключа. Службу Azure, запущенную от имени связанной подписки, можно настроить с помощью удостоверения в рамках этой подписки. Служба может выполнять проверку подлинности Microsoft Entra и получать маркер проверки подлинности, определяющий себя как эта служба, выступающая от имени подписки. Затем этот маркер можно представить в Key Vault, чтобы получить ключ, к которому он был предоставлен доступ.
Для операций с использованием ключей шифрования удостоверению службы можно предоставить доступ к любой из следующих операций: расшифровка, шифрование, упаковка, распаковка, проверка, подписывание, получение, перечисление, обновление, создание, импорт, удаление, резервное копирование и восстановление.
Чтобы получить ключ для шифрования или расшифровки неактивных данных, удостоверение службы, запущенное экземпляром службы диспетчера ресурсов, должно иметь ключ распаковки (чтобы получить ключ для расшифровки) и ключ упаковки (чтобы вставить ключ в хранилище ключей при создании нового ключа).
Примечание.
Дополнительные сведения об авторизации в хранилище ключей см. в статье Защита хранилища ключей.
Преимущества
- Полный контроль над используемыми ключами – управление ключами шифрования производится в хранилище ключей клиента под его контролем.
- Возможность шифрования нескольких служб с помощью главного ключа.
- Возможность отделить управление ключами от общей модели управления для службы.
- Возможность определить службу и расположение ключа в нескольких регионах.
Недостатки
- Пользователь полностью отвечает за управление доступом к ключам.
- Пользователь полностью отвечает за управление жизненным циклом ключей.
- Дополнительные издержки в процессе установки и конфигурации.
Шифрование на стороне сервера с использованием администрируемых пользователем ключей на управляемом пользователем оборудовании
Некоторые службы Azure допускают использование модели управления с размещением собственного ключа (HYOK). Этот режим управления рекомендуется для использования в сценариях, в которых необходимо шифровать данные в состоянии хранения и управлять ключами в собственном репозитории без участия корпорации Майкрософт. В этой модели служба должна использовать ключ из внешнего сайта для расшифровки ключа шифрования данных (DEK). Затрагиваются гарантии производительности и доступности, а конфигурация сложнее. Кроме того, так как служба имеет доступ к ключу шифрования данных во время операции шифрования и расшифровки, общие гарантии безопасности этой модели аналогичны модели, в которой ключами управляют пользователи в Azure Key Vault. В результате эта модель не подходит для большинства организаций, если они не имеют конкретных требований к управлению ключами. Из-за этих ограничений большинство служб Azure не поддерживают шифрование на стороне сервера с помощью ключей, управляемых клиентом, в оборудовании, управляемом клиентом. Один из двух ключей в шифровании двойных ключей следует этой модели.
Доступ к ключам
При использовании шифрования на стороне сервера с помощью ключей, управляемых клиентом, в оборудовании, управляемом клиентом, ключи шифрования ключей сохраняются в системе, настроенной клиентом. Службы Azure, которые поддерживают эту модель, предоставляют средства для создания безопасного подключения к хранилищу ключей, предоставленному пользователем.
Преимущества
- Полный контроль над корневым ключом. Ключи шифрования управляются в хранилище пользователя.
- Возможность шифрования нескольких служб с помощью главного ключа.
- Возможность отделить управление ключами от общей модели управления для службы.
- Возможность определить службу и расположение ключа в нескольких регионах.
Недостатки
- Полная ответственность за хранение ключей, безопасность, производительность и доступность.
- Полная ответственность за управление доступом к ключам.
- Полная ответственность за управление жизненным циклом ключей.
- Значительные расходы на установку, настройку и текущее обслуживание.
- Повышенная зависимость от доступности сети между центрами обработки данных Azure и центром обработки данных пользователя.