Безопасность Azure Key Vault при взломе

Question

Я хочу повысить свою безопасность своего веб-приложения в случае атаки. следующие компоненты присутствуют в моей системе:

• Azure Web App
• Azure Blob Storage
• Azure SQL Azure
• Azure KeyVault

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

1) Пользователь Загрузка документ на вебе-приложение ключа 2) случайного шифрования генерируется ключа 3) случайная шифровании хранится в лазурном ключе хранилище 4) SQL Azure хранит URL объекта Blob и ключевой url

Теперь мой вопрос: Как безопасно использовать ключ хранилища в случае взлома экземпляра веб-приложения? Я имею в виду, что клиентский идентификатор и клиентский секрет в app.config для доступа к keyvault, мы нуждаемся в нем для чтения и записи ключей. Так что если я использую ключевое хранилище или нет, это не повышает безопасность с точки зрения взлома веб-приложения, верно?

Answer 1

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

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

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

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

Answer 2

Так что если я использую ключевое хранилище или нет, это не повышает безопасность с точки зрения взлома веб-приложения, правильно?

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

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

Answer 3

Проблема не в ключевых хранилищах, а в вашем решении использовать секрет клиента. Секрет клиента - это постоянная строка, которая не считается безопасной. Вы можете использовать сертификат и отпечаток пальца как «секрет клиента». Вашему приложению необходимо прочитать файл .pfx, который хранится в веб-приложении, а затем расшифровать, чтобы захватить отпечаток. Как только отпечаток успешно восстановлен, секрет секретного ключа будет восстановлен. Кроме того, в Key Vault вам предоставляется возможность использовать свой собственный сертификат, а не только скрытую строку в Secret. Это так называемое «вложенное шифрование».

Хакер, если получить доступ к вашему app.config, он ничего не получит, чем путь PFX-файла, который он не знает, где хранить, даже как она выглядит. Создание одного и того же файла pfx становится невозможным. Если бы он мог сломать весь крипто-мир.