Поделиться через

Механизм безопасности. Проверка подлинности | Устранение рисков

  • Статья
Продукт или служба Статья
Веб-приложение
База данных
Концентратор событий Azure
Граница доверия Azure
Граница доверия Service Fabric
Сервер удостоверений
Граница доверия между компьютерами
WCF
Веб-API
Microsoft Entra ID
Полевой шлюз Интернета вещей
Облачный шлюз Интернета вещей
Хранилище Azure

Рассмотрите возможность использования стандартного механизма проверки подлинности в веб-приложениях

Заголовок Сведения
Компонент Веб-приложение
Этап SDL Сборка
Применимые технологии Универсальный
Атрибуты Н/П
Ссылки Н/П
Сведения

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

  • Сертификаты клиентов
  • на основе Windows;
  • на основе форм;
  • федерация: ADFS;
  • Федерация — идентификатор Microsoft Entra
  • федерация: сервер удостоверений.

Рассмотрите возможность использования стандартного механизма проверки подлинности для идентификации исходного процесса.

Приложения должны надежно обрабатывать сценарии неудачной проверки подлинности

Заголовок Сведения
Компонент Веб-приложение
Этап SDL Сборка
Применимые технологии Универсальный
Атрибуты Н/П
Ссылки Н/П
Сведения

Приложения, которые явно проходят проверку подлинности пользователей, должны безопасно обрабатывать сценарии проверки подлинности сбоем. Механизм проверки подлинности должен:

  • запрещать доступ к привилегированным ресурсам при сбое проверки подлинности;
  • отображать общее сообщение об ошибке после неудачной проверки подлинности и запрета доступа.

Проверьте, обеспечивает ли механизм проверки подлинности следующее:

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

    Включите проверку подлинности повышенного уровня или адаптивную проверку подлинности

    Заголовок Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Н/П
    Сведения

    Убедитесь, что приложение имеет дополнительную авторизацию (например, шаг вверх или адаптивную проверку подлинности, через многофакторную проверку подлинности, например отправку OTP в SMS, электронную почту и т. д. или запрос на повторную проверку подлинности), чтобы пользователь был оспорен перед предоставлением доступа к конфиденциальной информации. Это правило также применяется для внесения критически важных изменений в учетную запись или в действие.

    Это означает, что адаптация проверки подлинности должна быть реализована таким образом, чтобы приложение правильно применяло контекстно-зависимую авторизацию и не допускало несанкционированные манипуляции, например путем изменения параметров.

    Интерфейсы администрирования должны быть заблокированы соответствующим образом

    Заголовок Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Н/П
    Сведения Для начала предоставьте доступ к интерфейсу администрирования только для исходного диапазона IP-адресов. Если это решение не возможно, то всегда рекомендуется применять поэтапное или адаптивное аутентификацию для входа в административный интерфейс.

    Реализуйте безопасный механизм восстановления пароля

    Заголовок Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Н/П
    Сведения

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

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

    Настройте применение политик учетных записей и паролей

    Заголовок Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Н/П
    Сведения

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

    Для защиты от атак методом прямого подбора и подбора на основе словаря необходимо реализовать политику надежных паролей, чтобы пользователи создавали сложные пароли (например, длиной не менее 12 символов, а также содержащие алфавитно-цифровые или специальные символы).

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

    • Мягкая блокировка. Может быть хорошим вариантом для защиты пользователей от атак методом прямого подбора. Например, всякий раз, когда пользователь вводит неверный пароль три раза подряд, приложение может заблокировать учетную запись на минуту, чтобы замедлить процесс прямого подбора пароля, сделав его менее выгодным для злоумышленника. Если в этом случае реализовать жесткую блокировку, это приведет к отказу в обслуживании и окончательно заблокирует учетные записи. Кроме того, приложение может создать OTP (один разовый пароль) и отправить его вне диапазона (через электронную почту, sms и т. д.) пользователю. Другим подходом может быть реализация CAPTCHA после достижения порогового числа неудачных попыток.
    • Жесткая блокировка. Этот тип блокировки следует применять всякий раз при обнаружении атаки пользователя на ваше приложение. В качестве контрмеры можно окончательно заблокировать его учетную запись до тех пор, пока группа реагирования не проведет экспертизу. После этой процедуры вы можете разблокировать учетную запись пользователя или принять в отношении него дальнейшие юридические меры. Такой подход не позволит злоумышленнику продолжить атаки на приложение и инфраструктуру.

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

    Если приложение автоматически создает пароли, они должны создаваться случайным образом и иметь высокий уровень энтропии.

    Реализуйте элементы управления для предотвращения перечисления имен пользователей

    Заголовок Сведения
    Компонент Веб-приложение
    Этап SDL Сборка
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Н/П
    Шаги Во избежание перечисления имен пользователей все сообщения об ошибках должны быть обобщенными. Кроме того, иногда не удается избежать утечки информации в функциональных возможностях, таких как страница регистрации. В таких случаях, чтобы предотвратить автоматизированные атаки, необходимо использовать методы ограничения скорости обращений к странице, например CAPTCHA.

    По возможности используйте проверку подлинности Windows для подключения к SQL Server

    Заголовок Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии Локально
    Атрибуты Версия SQL: все
    Ссылки Выбор режима проверки подлинности
    Шаги Режим проверки подлинности Windows использует протокол безопасности Kerberos, реализует политику паролей в отношении проверки сложности надежных паролей, поддерживает блокировку учетных записей и истечение срока пароля.

    По возможности используйте проверку подлинности Microsoft Entra для подключения к База данных SQL

    Заголовок Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии SQL Azure
    Атрибуты Версия SQL: 12
    Ссылки Подключение к База данных SQL с помощью проверки подлинности Microsoft Entra
    Шаги Минимальная версия: База данных SQL Azure версии 12, необходимой для разрешения База данных SQL Azure использовать проверку подлинности Microsoft Entra в Microsoft Directory

    Если используется режим проверки подлинности SQL, обеспечьте применение политики учетных записей и паролей на сервере SQL Server

    Заголовок Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Политика паролей
    Шаги При использовании проверки подлинности SQL Server имена входа создаются в SQL Server, которые не основаны на учетных записях пользователей Windows. Имя пользователя и пароль создаются и хранятся в SQL Server. SQL Server может использовать механизмы политики паролей Windows. К паролям, используемым в SQL Server, можно применить те же политики ограничения срока действия и сложности, которые применяются в Windows.

    Не используйте проверку подлинности SQL в автономных базах данных

    Заголовок Сведения
    Компонент База данных
    Этап SDL Сборка
    Применимые технологии Локальная среда SQL Azure
    Атрибуты Версия SQL: MSSQL2012, версия SQL: 12
    Ссылки Рекомендации по защите автономных баз данных
    Шаги Отсутствие принудительной политики паролей может повысить вероятность установления слабых учетных данных в автономной базе данных. Используйте проверку подлинности Windows.

    Используйте учетные данные проверки подлинности на уровне отдельного устройства с помощью маркеров SaS

    Заголовок Сведения
    Компонент Центры событий Azure
    Этап SDL Сборка
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Общие сведения о проверке подлинности в Центрах событий Azure и модели безопасности
    Шаги

    В основе модели безопасности Центров событий лежит сочетание издателей событий и маркеров подписанных URL-адресов (SAS). Имя издателя представляет идентификатор устройства, которое получает маркер. Это поможет связать маркеры, созданные с помощью соответствующих устройств.

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

    Включение многофакторной проверки подлинности Microsoft Entra для администраторов Azure

    Заголовок Сведения
    Компонент Граница доверия Azure
    Этап SDL Развертывание
    Применимые технологии Универсальный
    Атрибуты Н/П
    Ссылки Что такое многофакторная проверка подлинности Microsoft Entra?
    Шаги

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

    • Что-то, что известно вам (обычно это пароль).
    • То, что у вас есть (надежное устройство, которое не легко дублируется, например телефон)
    • Что-то, относящееся непосредственно к вам (биометрические данные).

      Запретите анонимный доступ к кластеру Service Fabric

      Заголовок Сведения
      Компонент Граница доверия Service Fabric
      Этап SDL Развертывание
      Применимые технологии Универсальный
      Атрибуты Среда: Azure
      Ссылки Сценарии защиты кластера Service Fabric
      Шаги

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

      При создании кластера Service Fabric убедитесь, что для режима безопасности задано значение "seсure", и настройте требуемый сертификат сервера X.509. Создание незащищенного кластера позволит любому анонимному пользователю подключаться к нему, если конечные точки управления кластером общедоступны через Интернет.

      Сертификат Service Fabric для обмена данными между клиентом и узлом должен отличаться от простого сертификата для обмена данными между узлами

      Заголовок Сведения
      Компонент Граница доверия Service Fabric
      Этап SDL Развертывание
      Применимые технологии Универсальный
      Атрибуты Среда: Azure, автономная
      Ссылки Сценарии защиты кластера Service Fabric, Безопасное подключение к кластеру
      Шаги

      Безопасность обмена данными между клиентами и узлами на основе сертификатов настраивается при создании кластера (на портале Azure, с помощью шаблонов Resource Manager или автономного шаблона JSON). Для этого указывается сертификат клиента администрирования и (или) пользовательский сертификат клиента.

      Эти сертификаты должны отличаться от основного и дополнительного сертификатов, указанных для защиты обмена данными между узлами.

      Использование идентификатора Microsoft Entra для проверки подлинности клиентов в кластерах Service Fabric

      Заголовок Сведения
      Компонент Граница доверия Service Fabric
      Этап SDL Развертывание
      Применимые технологии Универсальный
      Атрибуты Среда: Azure
      Ссылки Рекомендации по обеспечению безопасности
      Шаги Кластеры, работающие в Azure, также могут защитить доступ к конечным точкам управления с помощью идентификатора Microsoft Entra, кроме сертификатов клиента. Для кластеров Azure рекомендуется использовать безопасность Microsoft Entra для проверки подлинности клиентов и сертификатов для безопасности узлов и узлов.

      Нужно использовать сертификаты Service Fabric, полученные из утвержденного Центра сертификации

      Заголовок Сведения
      Компонент Граница доверия Service Fabric
      Этап SDL Развертывание
      Применимые технологии Универсальный
      Атрибуты Среда: Azure
      Ссылки Сертификаты X.509 и Service Fabric
      Шаги

      Для проверки подлинности узлов и клиентов Service Fabric использует сертификаты сервера X.509.

      При использовании сертификатов в Service Fabric следует учитывать некоторые важные моменты:

      • Сертификаты, которые используются в кластерах, выполняющих рабочие нагрузки в рабочей среде, следует создать с помощью правильно настроенной службы сертификации Windows Server или получить из утвержденного центра сертификации. Центр сертификации может быть утвержденным внешним центром сертификации или правильно управляемой внутренней инфраструктурой открытых ключей (PKI).
      • Никогда не используйте в рабочей среде какие-либо временные или тестовые сертификаты, созданные с помощью таких инструментов, как MakeCert.exe.
      • Можно использовать самозаверяющий сертификат, но это следует делать только для тестовых кластеров, а не в рабочей среде.

      Используйте стандартные сценарии проверки подлинности, поддерживаемые сервером удостоверений

      Заголовок Сведения
      Компонент Сервер удостоверений
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки IdentityServer3. Общая картина
      Шаги

      Ниже приведены типичные взаимодействия, поддерживаемые сервером удостоверений.

      • Браузеры взаимодействуют с веб-приложениями.
      • Веб-приложения взаимодействуют с веб-API (иногда самостоятельно, иногда от имени пользователя).
      • Браузерные приложения взаимодействуют с веб-API.
      • Собственные приложения взаимодействуют с веб-API.
      • Серверные приложения взаимодействуют с веб-API.
      • Веб-API взаимодействуют с веб-API (иногда самостоятельно, иногда от имени пользователя).

      Переопределите кэш маркеров сервера удостоверений по умолчанию масштабируемым альтернативным кэшем

      Заголовок Сведения
      Компонент Сервер удостоверений
      Этап SDL Развертывание
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Развертывание сервера удостоверений. Кэширование
      Шаги

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

      • Доступ к этим приложениям осуществляют несколько пользователей одновременно. Если сохранять все маркеры доступа в одном хранилище, могут возникнуть трудности с изоляцией, которые вызовут проблемы при увеличении масштаба. При множестве пользователей с количеством маркеров, равным количеству ресурсов, к которым приложение обращается от их имени, может стать больше ресурсоемких операций поиска сопоставлений.
      • Эти приложения обычно развертываются в распределенной топологии, где несколько узлов должны иметь доступ к одному кэшу.
      • Кэшированные маркеры должны выдерживать перезапуски и деактивации процесса.
      • По указанным выше причинам при реализации веб-приложений рекомендуется переопределить кэш маркеров сервера удостоверений по умолчанию масштабируемым альтернативным кэшем, например кэшем Azure для Redis.

      Двоичные файлы развернутого приложения должны иметь цифровую подпись

      Заголовок Сведения
      Компонент Граница доверия между компьютерами
      Этап SDL Развертывание
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Н/П
      Шаги Убедитесь, что все двоичные файлы развернутого приложения имеют цифровую подпись, что дает возможность проверить их целостность.

      Включите проверку подлинности при подключении к очередям MSMQ в WCF

      Заголовок Сведения
      Компонент WCF
      Этап SDL Сборка
      Применимые технологии Универсальные, .NET Framework 3
      Атрибуты Н/П
      Ссылки MSDN
      Шаги Если при подключении к очередям MSMQ программе не удается включить проверку подлинности, злоумышленник может анонимно отправить сообщения в очередь для обработки. Если для подключения к очереди MSMQ, которая используется для доставки сообщения в другую программу, проверка подлинности отсутствует, злоумышленник может анонимно отправить вредоносное сообщение.

      Пример

      Элемент <netMsmqBinding/> расположенного ниже файла конфигурации WCF указывает WCF отключить проверку подлинности при подключении к очереди MSMQ для доставки сообщений.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      Настройте в MSMQ обязательную проверку подлинности сертификата или домена Windows для всех входящих или исходящих сообщений.

      Пример

      Элемент <netMsmqBinding/> расположенного ниже файла конфигурации WCF указывает WCF включить проверку подлинности сертификата при подключении к очереди MSMQ. Клиент проходит проверку подлинности с использованием сертификатов X.509. Сертификат клиента должен присутствовать в хранилище сертификатов сервера.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      WCF: не присваивайте атрибуту message clientCredentialType значение None

      Заголовок Сведения
      Компонент WCF
      Этап SDL Сборка
      Применимые технологии .NET Framework 3
      Атрибуты Тип учетных данных клиента: None
      Ссылки MSDN, Fortify
      Шаги Отсутствие проверки подлинности означает, что каждый может получить доступ к этой службе. Служба, которая не выполняет проверку подлинности своих клиентов, предоставляет доступ всем пользователям. Настройте в приложении проверку подлинности учетных данных клиента. Это можно сделать, задав для атрибута message clientCredentialType значение Windows или Certificate.

      Пример

      <message clientCredentialType=""Certificate""/>

      WCF: не присваивайте атрибуту transport clientCredentialType значение None

      Заголовок Сведения
      Компонент WCF
      Этап SDL Сборка
      Применимые технологии Универсальные, .NET Framework 3
      Атрибуты Тип учетных данных клиента: None
      Ссылки MSDN, Fortify
      Шаги Отсутствие проверки подлинности означает, что каждый может получить доступ к этой службе. Служба, которая не выполняет проверку подлинности своих клиентов, предоставляет доступ к своим функциям всем пользователям. Настройте в приложении проверку подлинности учетных данных клиента. Это можно сделать, задав для атрибута transport clientCredentialType значение Windows или Certificate.

      Пример

      <transport clientCredentialType=""Certificate""/>

      Для защиты веб-API нужно использовать стандартные методы проверки подлинности

      Заголовок Сведения
      Компонент Веб-интерфейс API
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Проверка подлинности и авторизация в веб-API ASP.NET, сведения о внешних службах проверки подлинности с веб-API ASP.NET (C#)
      Шаги

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

      • Сертификаты клиентов
      • на основе Windows;
      • на основе форм;
      • федерация: ADFS;
      • Федерация — идентификатор Microsoft Entra
      • федерация: сервер удостоверений.

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

      Использование стандартных сценариев проверки подлинности, поддерживаемых идентификатором Microsoft Entra

      Заголовок Сведения
      Компонент Microsoft Entra ID
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Сценарии проверки подлинности для идентификатора Microsoft Entra, примеры кода Microsoft Entra, руководство разработчика Microsoft Entra
      Шаги

      Идентификатор Microsoft Entra упрощает проверку подлинности для разработчиков, предоставляя удостоверение как услугу, с поддержкой стандартных отраслевых протоколов, таких как OAuth 2.0 и OpenID Connect. Ниже приведены пять сценариев основных приложений, поддерживаемых идентификатором Microsoft Entra:

      • Веб-браузер для веб-приложения: пользователю необходимо войти в веб-приложение, защищенное идентификатором Microsoft Entra.
      • Одностраничные приложения (SPA): пользователю необходимо войти в одностраничное приложение, защищенное идентификатором Microsoft Entra.
      • Собственное приложение к веб-API: собственное приложение, работающее на телефоне, планшете или компьютере, должно пройти проверку подлинности пользователя для получения ресурсов из веб-API, защищенного идентификатором Microsoft Entra.
      • Веб-приложение к веб-API: веб-приложение должно получать ресурсы из веб-API, защищенного идентификатором Microsoft Entra
      • Управляющая программа или серверное приложение для веб-API: приложение управляющей программы или серверное приложение без веб-интерфейса не должно получать ресурсы из веб-API, защищенного идентификатором Microsoft Entra

      Используйте ссылки в разделе справочных сведений, чтобы получить низкоуровневые сведения о реализации.

      Переопределите кэш маркеров MSAL по умолчанию с распределенным кэшем

      Заголовок Сведения
      Компонент Microsoft Entra ID
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Сериализация кэша маркеров в MSAL.NET
      Шаги

      По умолчанию используется кэш MSAL (библиотека проверки подлинности Майкрософт) — это кэш в памяти и масштабируемый. Однако существуют различные варианты, которые можно использовать в качестве альтернативы, например кэш распределенных маркеров. Они имеют механизмы L1/L2, где L1 находится в памяти, а L2 — реализация распределенного кэша. Их можно настроить соответствующим образом, чтобы ограничить память L1, зашифровать или задать политики вытеснения. Другие варианты включают Redis, SQL Server или кэши Azure Cosmos DB. Реализация распределенного кэша маркеров можно найти в следующем руководстве. Начало работы с ASP.NET Core MVC.

      Убедитесь, что TokenReplayCache используется для предотвращения воспроизведения маркеров проверки подлинности MSAL

      Заголовок Сведения
      Компонент Microsoft Entra ID
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Современная проверка подлинности с помощью идентификатора Microsoft Entra для веб-приложений
      Шаги

      Свойство TokenReplayCache позволяет разработчикам определять кэш воспроизведения маркеров, хранилище, которое можно использовать для сохранения маркеров, чтобы предотвратить использование повторяющихся маркеров.

      Эта мера защиты от распространенных атак с использованием воспроизведения маркеров. Злоумышленник, который перехватывает маркер, отправленный при входе в систему, может попытаться снова отправить его в приложение ("воспроизвести" его), чтобы создать новый сеанс. Например, в потоке предоставления кода OIDC после успешной проверки подлинности пользователя запрос к конечной точке "/signin-oidc" проверяющей стороны выполняется с параметрами "id_token", "code" и "state".

      Проверяющая сторона проверяет запрос и создает новый сеанс. Если злоумышленник перехватил и воспроизвел этот запрос, он может успешно создать сеанс, выдав себя за пользователя. Наличие специального утверждения в OpenID Connect может ограничить, но не полностью исключить подобные атаки. Чтобы защитить свои приложения, разработчики могут реализовать интерфейс ITokenReplayCache и присвоить экземпляр свойству TokenReplayCache.

      Пример

      // ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

      Пример

      Ниже приведен пример реализации интерфейса ITokenReplayCache. (Выполните соответствующие настройки и реализуйте платформу кэширования конкретного проекта.)

      public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

      Ссылку на реализованный кэш нужно добавить в параметрах OIDC с помощью свойства TokenValidationParameters следующим образом.

      OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

      Обратите внимание, что для проверки эффективности этой конфигурации войдите в локальное приложение с защитой OIDC и запишите запрос к "/signin-oidc" конечной точке в fiddler. Если защита не включена, воспроизведение этого запроса в Fiddler приведет к созданию нового файла cookie сеанса. При воспроизведении запроса после добавления защиты с помощью свойства TokenReplayCache приложение выдаст исключение следующего типа: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      Использование библиотек MSAL для управления запросами маркеров от клиентов OAuth2 к идентификатору Microsoft Entra (или локальному AD)

      Заголовок Сведения
      Компонент Microsoft Entra ID
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки MSAL
      Шаги

      Библиотека проверки подлинности Майкрософт (MSAL) позволяет разработчикам получать маркеры безопасности из платформа удостоверений Майкрософт для проверки подлинности пользователей и доступа к защищенным веб-API. Она может использоваться для обеспечения безопасного доступа к Microsoft Graph, другим API-интерфейсам Майкрософт, веб-API сторонних производителей или к собственному веб-API. MSAL поддерживает множество различных архитектур приложений и платформ, в том числе .NET, JavaScript, Java, Python, Android и iOS.

      MSAL предоставляет множество способов получения маркеров с согласованным API для многих платформ. Нет необходимости напрямую использовать библиотеки OAuth или код для протокола в приложении и получать маркеры от имени пользователя или приложения (если применимо к платформе).

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

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

      Заголовок Сведения
      Компонент Полевой шлюз Интернета вещей
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Н/П
      Шаги Настройте полевой шлюз таким образом, чтобы он выполнял проверку подлинности каждого устройства, прежде чем получать от них данные и упрощать взаимодействие вышестоящих объектов с облачным шлюзом. Кроме того, настройте подключение устройств с помощью учетных данных на уровне отдельного устройства, чтобы уникально идентифицировать отдельные устройства.

      Устройства, подключаемые к облачному шлюзу, должны проходить проверку подлинности

      Заголовок Сведения
      Компонент Облачный шлюз Интернета вещей
      Этап SDL Сборка
      Применимые технологии Generic, C#, Node.js,
      Атрибуты Н/д, выбор шлюза: Центр Интернета вещей Azure
      Ссылки Н/Д, Приступая к работе с Центром Интернета вещей Azure (.NET), Приступая к работе с Центром Интернета вещей Azure (Node), Использование SAS и сертификатов для защиты Интернета вещей, Репозиторий Git
      Шаги
      • Универсальное. Выполняйте проверку подлинности устройства с использованием протокола TLS или IPSec. Инфраструктура должна поддерживать общие ключи для тех устройств, которые не выполняют полное асимметричное шифрование. Используйте идентификатор Microsoft Entra, OAuth.
      • C#. При создании экземпляра DeviceClient по умолчанию метод Create создает экземпляр DeviceClient, который использует протокол AMQP для связи с Центром Интернета вещей. Для использования протокола HTTPS используйте переопределение метода Create, чтобы указать протокол. Если вы используете протокол HTTPS, вам также следует добавить в свой проект пакет NuGet Microsoft.AspNet.WebApi.Client, чтобы включить пространство имен System.Net.Http.Formatting.

      Пример

      static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

      Пример

      Node.js: проверка подлинности

      Симметричный ключ

      • Создайте Центр Интернета вещей в Azure
      • Создание записи в реестре удостоверений устройства 
        var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})
      • Создание имитированного устройства 
        var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
var Message = require('azure-iot-device').Message;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
var client = clientFromConnectionString(connectionString);

        Маркер SAS

      • Создается в системе при использовании симметричного ключа, но его также можно создать и использовать явным образом.
      • Определите протокол: var Http = require('azure-iot-device-http').Http;
      • Создание маркера sas: 
        resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
var deviceName = "<deviceName >";
var expires = (Date.now() / 1000) + expiresInMins * 60;
var toSign = resourceUri + '\n' + expires;
// using crypto
var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
const hmac = crypto.createHmac('sha256', decodedPassword);
hmac.update(toSign);
var base64signature = hmac.digest('base64');
var base64UriEncoded = encodeURIComponent(base64signature);
// construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;
      • Подключение с помощью маркера sas: 
        Client.fromSharedAccessSignature(sas, Http);

        Сертификаты

      • Создайте самозаверяющий сертификат X509 с помощью любого средства, такого как OpenSSL, чтобы создать файлы CERT и KEY для хранения сертификата и ключа соответственно.
      • Подготовьте устройство, которое принимает безопасное подключение с использованием сертификатов. 
        var connectionString = '<connectionString>';
var registry = iothub.Registry.fromConnectionString(connectionString);
var deviceJSON = {deviceId:"<deviceId>",
authentication: {
    x509Thumbprint: {
    primaryThumbprint: "<PrimaryThumbprint>",
    secondaryThumbprint: "<SecondaryThumbprint>"
    }
}}
var device = deviceJSON;
registry.create(device, function (err) {});
      • Подключение устройства с помощью сертификата 
        var Protocol = require('azure-iot-device-http').Http;
var Client = require('azure-iot-device').Client;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
var client = Client.fromConnectionString(connectionString, Protocol);
var options = {
    key: fs.readFileSync('./key.pem', 'utf8'),
    cert: fs.readFileSync('./server.crt', 'utf8')
};
// Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
client.setOptions(options);
//call fn to execute after the connection is set up
client.open(fn);

      Используйте учетные данные проверки подлинности на уровне отдельного устройства

      Заголовок Сведения
      Компонент Облачный шлюз Интернета вещей
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Выбор шлюза: Центр Интернета вещей Azure
      Ссылки Маркеры безопасности Центра Интернета вещей Azure
      Шаги Используйте учетные данные проверки подлинности с помощью маркеров SAS на основе ключа устройства или сертификата клиента для каждого отдельного устройства вместо политик общего доступа на уровне Центра Интернета вещей. Это предотвратит повторное использование маркеров проверки подлинности одного устройства или полевого шлюза другим устройством.

      Анонимный доступ на чтение должен быть предоставлен только к необходимым контейнерам и большим двоичным объектам

      Заголовок Сведения
      Компонент Хранилище Azure
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Тип хранилища: большой двоичный объект
      Ссылки Управление анонимным доступом на чтение к контейнерам и большим двоичным объектам, Использование подписанных URL-адресов (SAS): общие сведения о модели SAS
      Шаги

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

      Доступны следующие возможности управления доступом к контейнеру.

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

      Анонимный доступ лучше всего подходит для сценариев, когда определенные большие двоичные объекты нужно сделать всегда доступными для анонимного доступа на чтение. Для осуществления детального контроля можно создать подписанный URL-адрес, который позволит делегировать ограниченный доступ на определенный временной интервал, используя разные разрешения. Убедитесь, что контейнеры и большие двоичные объекты, которые потенциально могут содержать конфиденциальные данные, не получают анонимный доступ случайно

      Предоставьте ограниченный доступ к объектам в службе хранилища Azure с помощью SAS или SAP

      Заголовок Сведения
      Компонент Хранилище Azure
      Этап SDL Сборка
      Применимые технологии Универсальный
      Атрибуты Н/П
      Ссылки Использование подписанных URL-адресов (SAS): общие сведения о модели SAS, Подписанные URL-адреса. Часть 2: создание и использование подписанного URL-адреса в службе BLOB-объектов, сведения о делегировании доступа к объектам в учетной записи с помощью подписанных URL-адресов и хранимых политик доступа
      Шаги

      Подписанный URL-адрес (SAS) — это эффективное средство для предоставления другим клиентам ограниченного доступа к объектам в вашей учетной записи хранения без предоставления ключа доступа к вашей учетной записи. Подпись общего доступа — это URI, который в своих параметрах запроса содержит все сведения, необходимые доступа к ресурсу хранилища с прохождением проверки подлинности. Для доступа к ресурсам хранилища с помощью SAS клиенту достаточно передать SAS в соответствующий конструктор или метод.

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

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