Разрешения на доступ к хранилищу ключей Azure и безопасность ключей

Я разрабатываю приложение .NET, которое загружает файлы в хранилище Azure. Я использую шифрование на стороне клиента, как описано в руководстве по адресу https://azure.microsoft.com/en-us/documentation/articles/storage-encrypt-decrypt-blobs-key-vault/

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

Однако у меня есть некоторые опасения по поводу безопасности ключа RSA. Если клиентское приложение получает ключ от Key Vault для использования в BlobEncryptionPolicy, этот ключ может быть скомпрометирован? Единственное, что действительно нужно приложению, - это открытый ключ пары RSA, закрытый ключ должен оставаться на сервере (расшифровка выполняется только доверенным веб-приложением).

Другое беспокойство, которое у меня вызывает, заключается в том, что получить информацию об интеграции AAD из app.config очень просто. Как можно обойти это?

(примечание: рабочие станции, на которых будет работать приложение загрузки, не обязательно являются доверенными)


person SvenAelterman    schedule 01.09.2015    source источник


Ответы (2)


Дополнительное чтение документа с пошаговым руководством по хранилищу Azure и Key Vault по адресу https://azure.microsoft.com/en-us/documentation/articles/storage-encrypt-decrypt-blobs-key-vault/ предоставил ответ:

Сам клиент хранилища никогда не имеет доступа к KEK.

KEK - это ключ шифрования ключа, который шифрует фактический одноразовый симметричный ключ шифрования, используемый для шифрования реального большого двоичного объекта.

person SvenAelterman    schedule 08.09.2015

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

Наконец, открытый ключ действительно не должен быть открытым ключом, он должен быть в сертификате X.509, чтобы вы могли проверить подлинность конечной точки сервера.

person MichaelHoward-MSFT    schedule 03.06.2020