#azure #certificate #azure-keyvault #secret-key
#лазурный #сертификат #azure-keyvault #секретный ключ
Вопрос:
Любой, кто может взломать мой код и получить идентификатор клиента, идентификатор арендатора и отпечаток пальца сертификата, может получить доступ к секретам, хранящимся в моем хранилище ключей. Итак, в чем разница между этим и простым сохранением секретных значений непосредственно в моем коде, где любой, кто взломает мой код, может прочитать?
Ответ №1:
Даже если кто-то смог получить эту информацию, ваше хранилище все равно будет в безопасности, поскольку для доступа к вашему хранилищу ключей и просмотра содержимого внутри необходимо будет добавить пользователя, приложение или идентификационные данные в плоскость управления хранилищем ключей (RBAC) и плоскость данных (политики доступа). чтобы просмотреть все, что находится в вашем хранилище.
Поэтому, если у пользователя есть идентификатор пользователя, у него все равно не будет доступа к вашему AKV, если у него нет учетных данных пользователя, приложения или удостоверения, которые имеют правильные разрешения RBAC и политики доступа.
Дополнительные сведения: Плоскость управления и плоскость данных Azure RBAC и политики доступа
Комментарии:
1. таким образом, все учетные данные, необходимые для доступа к хранилищу ключей, хранятся в моем коде (идентификатор клиента и клиента моей регистрации в приложении Azure AD и отпечаток пальца самоподписанного сертификата, который я создал и загрузил в хранилище ключей, подключенное к регистрации приложения через политику доступа), если хакер взломаетполучить их, а затем создать свое собственное программное обеспечение, используя эти учетные данные, чтобы получить секрет, как Azure узнает, что на его компьютере отсутствуют правильные разрешения rbac или политики доступа? Если я войду в систему на каком-либо другом компьютере и создам приложение с этими учетными данными, будет ли мне заблокирован доступ к хранилищу ключей?
2. @KyleTrent Мои рекомендации для вашего сценария: 1) Если ваш код размещен в Azure, затем перейдите в MSI. 2) Если ваш код размещен на-prem, затем используйте сертификат клиента для аутентификации AAD для получения токена доступа. Импортируйте сертификат клиента с помощью закрытого ключа, который нельзя экспортировать. 3) Заблокируйте политики доступа только к определенной информации, которая требуется клиентам. Поскольку AKV использует разрешения «все или ничего» для объектов (секрет, ключ, сертификат), используйте отдельные хранилища ключей, если требуется более точная детализация.
Ответ №2:
Для приложений, размещенных в Azure, предпочтительнее использовать управляемую идентификацию. Это отдельный принципал, в котором пароль никогда не становится доступным даже для кражи или утечки.
Если вы используете DefualtAzureCredential в пакетах SDK Azure, вы можете лучше настроить свое хранилище для сред разработки и производства. Вы можете предоставить ограниченные разрешения пользователям AAD, которые могут входить в систему через Visual Studio, Azure CLI, модуль Az PowerShell и другие. Без изменения кода ваше приложение может полагаться на управляемую идентификацию с собственным набором разрешений. Например, возможно, вы используете разные хранилища для производства и разработки, настроенные с помощью параметра, в котором управляемая идентификация имеет доступ на чтение к секретам / ключам, но ваши разработчики этого не делают — не в производственном хранилище. Управление доступом на основе ролей также внедряется в управляемое HSM (более безопасное аппаратное хранилище ключей), чтобы обеспечить основную степень детализации даже в том же хранилище.
Участники службы, использующие переменные среды, могут использоваться вместо управляемой идентификации, но в идеале должны быть зарезервированы только для вашей производственной среды. Разработчики также могут иметь его, но это, вероятно, означает совместное использование идентификаторов клиентов и секретов, что практически не смягчает ситуацию, если кто-то уйдет или произойдет утечка информации — в любом случае, это нелегкое смягчение.
Комментарии:
1. Я изучил управляемую идентификацию, но мне показалось, что мне нужно развернуть базу данных и приложение в Azure, чтобы использовать их. Моя база данных и сервер данных — это машина, на которую я подключаюсь по протоколу rdp и размещаю ее с помощью iss, а не в облаке Azure. Можно ли по-прежнему использовать управляемую идентификацию без размещения базы данных и приложения из облака Azure?