Блог

У меня есть приложение .Net 4.6.1, которому необходимо получить доступ к некоторым секретам из хранилища ключей Azure, и я делаю это следующим образом:

         var clientCredential = new ClientSecretCredential(
            azureClientData.AzureTenantId,
            azureClientData.AzureClientID,
            azureClientData.AzureClientSecret);

        _client = new SecretClient(keyVaultUri, clientCredential); 
 

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

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

         var clientCerCredential = new ClientCertificateCredential(
            azureClientData.AzureTenantId,
            azureClientData.AzureClientID,
            azureClientData.AzureClientCertificatePath); // Is it the local path to the certificate that is downloaded as CER/PEM format from Azure Key Vault ?



        _client = new CertificateClient(keyVaultUri, clientCredential); 
 

Является ли это локальным путем к сертификату, загруженному в формате CER/PEM из хранилища ключей Azure ?

« clientCertificatePath это путь к файлу, который содержит как сертификат клиента, так и закрытый ключ.» Это всегда локальный путь, но если вы сохраните его в OneDrive, путь будет иметь формат «C:UsersmyuserOneDrive — MicrosoftДокументыСертификаты».

если я работаю в частном облаке, действительно ли это имеет значение (секрет клиента / сертификат клиента)?

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

Существуют плюсы и минусы секретности клиента и сертификата клиента:

Секрет клиента:

Pro: Легко развертывается — требуется всего лишь немного кода и безопасное хранилище данных. В зависимости от политики безопасности может автоматически генерировать пароли или заставлять новых пользователей создавать их.

Pro: Простота администрирования — сброс паролей может (для некоторых политик безопасности) выполняться с помощью автоматизированных инструментов

Con: Для обеспечения хорошей безопасности пароли следует сбрасывать рано и часто. Забывание или неспособность пользователя изменить пароли-это либо угроза безопасности, либо проблема с удобством использования.

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

Кон: Хранилища данных паролей являются слабым местом — если злоумышленник получит хранилище паролей, он получит основную нагрузку.

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

Сертификаты:

Профи: Не требует передачи секрета. Доказательство наличия закрытого ключа не содержит секретной информации — устраняет всевозможные слабые места в хранении/передаче.

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

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

Pro: Служит не только для аутентификации, но и для обеспечения целостности и конфиденциальности.

Con: По — прежнему требуется пароль/pin-код-почти любой механизм хранения пары закрытых ключей затем разблокируется с помощью PIN-кода. Смарт-карты могут иметь функции защиты от несанкционированного доступа и блокировки для предотвращения применения грубой силы, но это не исправляет тот факт, что пользователь написал свой PIN-код на стикере рядом с компьютером, к которому прикреплена карта. Иногда проблемы с паролем возникают в меньшем масштабе с помощью PKI.

Con: Сложность инфраструктуры — настройка PKI-непростая задача и, как правило, настолько дорогостоящая как при развертывании, так и при обслуживании, что ее можно использовать только для больших/дорогих систем.

Con: Отчеты о состоянии сертификатов и обновления нелегки — отзыв учетных данных пользователя, которые были повреждены, является обременительным из-за размера и сложности инфраструктуры. Обычно центр сертификации генерирует список рассылки, который может быть предоставлен или не предоставлен на сервере OCSP. Затем каждое приложение должно проверять каждый вход в систему на наличие статуса CRL или OCSP. Это приводит к различным временным задержкам в системе между моментом, когда учетные данные PKI сообщаются как скомпрометированные, и временем, когда системы, которые полагаются на эти учетные данные, фактически начинают отказывать в доступе. Скорость обновления статуса может быть ускорена, но за счет большей сложности системы.