Механизм безопасности. Авторизация | Устранение рисков

Продукт или служба	Статья
Граница доверия между компьютерами	Соответствующим образом настройте списки ACL для предотвращения несанкционированного доступа к данным на устройстве Конфиденциальное пользовательское содержимое приложения должно храниться в каталоге профиля пользователя Развернутые приложения следует запускать с минимальным числом привилегий
Веб-приложение	Обеспечьте последовательный порядок обработки потоков бизнес-логики Реализуйте ограничение частоты транзакций, чтобы предотвратить перечисление Обеспечьте применение соответствующего типа авторизации и соблюдение принципа наименьших необходимых привилегий Бизнес-логика и принятие решений об авторизации доступа к ресурсам не должны основываться на параметрах входящего запроса Убедитесь, что содержимое и ресурсы не могут быть перечислены или доступны путем несанкционированного просмотра
База данных	Убедитесь, что для подключения к серверу базы данных используются учетные записи с минимальными привилегиями доступа Реализуйте безопасность на уровне строк (RLS), чтобы запретить клиентам доступ к данным друг друга Роль системного администратора должна быть только у необходимых действительных пользователей
Облачный шлюз Интернета вещей	Подключайтесь к облачному шлюзу с помощью маркеров с минимальными привилегиями доступа
Концентратор событий Azure	Для создания маркеров устройства используйте ключ SAS с разрешениями только для отправки Не используйте маркеры доступа, которые предоставляют прямой доступ к концентратору событий Подключайтесь к концентратору событий, используя ключи SAS с минимальными необходимыми разрешениями
Azure DocumentDB	Использование маркеров ресурса (по возможности) для подключения к Cosmos DB
Граница доверия Azure	Обеспечение точного управление доступом к подписке Azure с помощью RBAC
Граница доверия Service Fabric	С помощью Azure RBAC ограничьте доступ клиента к операциям кластера
Dynamics CRM	Выполняйте моделирование безопасности, при необходимости применяя безопасность на уровне полей
Портал Dynamics CRM	Выполняйте моделирование безопасности учетных записей на портале с учетом отличия модели безопасности для портала от модели безопасности для CRM
Хранилище Azure	Предоставьте детальное разрешение диапазону сущностей в хранилище таблиц Azure Включение управления доступом на основе ролей Azure (Azure RBAC) в учетную запись хранения Azure с помощью Azure Resource Manager
Мобильный клиент	Реализуйте неявное обнаружение снятия защиты или получение административного доступа
WCF	Слабый механизм ссылки на класс в WCF Реализуйте контроль авторизации WCF
Веб-API	Реализуйте соответствующий механизм авторизации в веб-API ASP.NET
Устройство IoT	Выполняйте проверки авторизации на устройстве, если оно поддерживает действия, для которых требуются разрешения различных уровней
Полевой шлюз Интернета вещей	Выполняйте проверки авторизации в полевом шлюзе, если он поддерживает действия, для которых требуются разрешения различных уровней

Соответствующим образом настройте списки ACL для предотвращения несанкционированного доступа к данным на устройстве

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

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

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

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

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

Обеспечьте последовательный порядок обработки потоков бизнес-логики

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

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

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

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

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

Бизнес-логика и принятие решений об авторизации доступа к ресурсам не должны основываться на параметрах входящего запроса

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

Пример

SELECT data 
FROM personaldata 
WHERE userID=:id < - session var 

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

Убедитесь, что содержимое и ресурсы не могут быть перечислены или доступны путем несанкционированного просмотра

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

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

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

Реализуйте безопасность на уровне строк (RLS), чтобы запретить клиентам доступ к данным друг друга

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

Обратите внимание, что RLS, как готовая функция базы данных, применима только к SQL Server, начиная с версии 2016, к базе данных SQL Azure и управляемому экземпляру SQL. Если готовая функция RLS не реализована, необходимо ограничить доступ к данным с помощью представлений и процедур.

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

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

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

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

Для создания маркеров устройства используйте ключ SAS с разрешениями только для отправки

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

Не используйте маркеры доступа, которые предоставляют прямой доступ к концентратору событий

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

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

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

Использование маркеров ресурса (по возможности) для подключения к Cosmos DB

Заголовок	Сведения
Компонент	Azure DocumentDB
Этап SDL	Сборка
Применимые технологии	Универсальный
Атрибуты	Н/П
Ссылки	Н/П
Шаги	Маркер ресурса связан с разрешением Azure Cosmos DB и отражает отношение между пользователем базы данных и разрешением этого пользователя к конкретному ресурсу приложения Azure Cosmos DB (например, коллекции, документу). Всегда используйте маркер ресурса для доступа к Azure Cosmos DB, если клиенту (приложению пользователя, например клиенту мобильного или настольного приложения) невозможно доверить обработку главных ключей или ключей только для чтения. Используйте главный ключ или ключи только для чтения серверных приложений, которые могут хранить их безопасно.

Обеспечение точного управление доступом к подписке Azure с помощью RBAC

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

С помощью Service Fabric RBAC ограничьте доступ клиента к операциям кластера

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

Выполняйте моделирование безопасности, при необходимости применяя безопасность на уровне полей

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

Выполняйте моделирование безопасности учетных записей на портале с учетом отличия модели безопасности для портала от модели безопасности для CRM

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

Предоставьте детальное разрешение диапазону сущностей в хранилище таблиц Azure

Заголовок	Сведения
Компонент	Хранилище Azure
Этап SDL	Сборка
Применимые технологии	Универсальный
Атрибуты	Тип хранилища: таблица
Ссылки	Руководство по безопасности службы хранилища Azure. Делегирование доступа к объектам в учетной записи с помощью подписанных URL-адресов и хранимых политик доступа
Шаги	В некоторых бизнес-сценариях для хранения конфиденциальных данных, предназначенных для различных сторон, может потребоваться хранилище таблиц Azure. Это могут быть конфиденциальные данные, относящиеся к разным странам/регионам. В таких случаях подписи SAS можно создать, указав диапазоны ключей разделов и строк таким образом, чтобы пользователь мог обращаться к данным, относящимся к определенной стране/региону.

Включение управления доступом на основе ролей Azure (Azure RBAC) в учетную запись хранения Azure с помощью Azure Resource Manager

Заголовок	Сведения
Компонент	Хранилище Azure
Этап SDL	Сборка
Применимые технологии	Универсальный
Атрибуты	Н/П
Ссылки	Защита учетной записи хранения с помощью управления доступом на основе ролей (Azure RBAC)
Шаги	При создании учетной записи хранения необходимо выбрать модель развертывания: классическую или на основе Azure Resource Manager. Классическая модель создания ресурсов в Azure обеспечивает доступ к подписке, а, следовательно, и к учетной записи хранения, только по принципу "все или ничего". С помощью модели Azure Resource Manager вы помещаете учетную запись хранения в группу ресурсов и управляете доступом к плоскости управления этой конкретной учетной записи хранения с помощью идентификатора Microsoft Entra. Например, вы можете предоставить определенным пользователям доступ к ключам учетной записи хранения, а другим — запретить такой доступ, но разрешить просматривать информацию об учетной записи.

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

Заголовок	Сведения
Компонент	Мобильный клиент
Этап SDL	Сборка
Применимые технологии	Универсальный
Атрибуты	Н/П
Ссылки	Н/П
Шаги	Приложение должно обеспечить защиту собственной конфигурации и данных пользователя в случае, если обнаружено, что на телефоне снята защита или к нему получен административный доступ. Такие случаи подразумевают, что злоумышленник имеет несанкционированный доступ к телефону. Поэтому при запуске приложения должна выполняться логика неявного обнаружения, позволяющая обнаружить получение административного доступа. Логика обнаружения может легко обращаться к файлам, доступ к которым обычно имеет только привилегированный пользователь, например: /system/app/Superuser.apk; /sbin/su; /system/bin/su; /system/xbin/su; /data/local/xbin/su; /data/local/bin/su; /system/sd/xbin/su; /system/bin/failsafe/su; /data/local/su. Если приложение может получить доступ к любому из этих файлов, это означает, что оно выполняется с привилегированного пользователя.

Слабый механизм ссылки на класс в WCF

Заголовок	Сведения
Компонент	WCF
Этап SDL	Сборка
Применимые технологии	Универсальные, .NET Framework 3
Атрибуты	Н/П
Ссылки	MSDN, Fortify Kingdom
Шаги	Система использует слабый механизм ссылки на класс, который может позволить злоумышленнику выполнить несанкционированный код. Программа ссылается на пользовательский класс, который идентифицируется неоднозначно. Когда .NET загружает этот слабо идентифицируемый класс, загрузчик среды типа CLR ищет класс в следующих местоположениях в указанном порядке: Если сборка типа известна, загрузчик выполняет поиск в расположениях перенаправления файла конфигурации, в глобальном кэше сборок, в текущей сборке с помощью сведений о конфигурации и в базовом каталоге приложения. Если сборка неизвестна, загрузчик ищет в текущей сборке, в файле mscorlib и в месте, возвращаемом обработчиком событий TypeResolve. Можно изменить порядок поиска среды CLR с помощью таких обработчиков, как механизм пересылки типа и событие AppDomain.TypeResolve. Если злоумышленник использует порядок поиска среды CLR, создав альтернативный класс с тем же именем и поместив его в альтернативное расположение, которое среда CLR загрузит сначала, среда CLR непреднамеренно выполнит предоставленный злоумышленником код.

Пример

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

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""MyBehavior"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

Использование полных (надежных) имен однозначно определяет тип и повышает безопасность системы. Используйте полные имена сборок при регистрации типов в файлах machine.config и app.config.

Пример

Элемент <behaviorExtensions/> расположенного ниже файла конфигурации WCF указывает WCF добавить настраиваемый класс поведения с надежным механизмом ссылки в определенное расширение WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
            Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

Реализуйте контроль авторизации WCF

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

Пример

Следующая конфигурация указывает WCF не проверять уровень авторизации клиента при выполнении службы:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""None"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Используйте схему авторизации службы, чтобы убедиться, что объект, вызывающий метод службы, авторизован выполнять это действие. WCF работает в двух режимах и позволяет определить настраиваемую схему авторизации. Для проверки подлинности в режиме UseWindowsGroups используются роли и пользователи Windows, а в режиме UseAspNetRoles используется поставщик ролей ASP.NET, например SQL Server.

Пример

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

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""UseWindowsGroups"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Затем служба объявляется следующим образом:

[PrincipalPermission(SecurityAction.Demand,
Role = ""Builtin\\Administrators"")]
public double Add(double n1, double n2)
{
double result = n1 + n2;
return result;
}

Реализуйте соответствующий механизм авторизации в веб-API ASP.NET

Заголовок	Сведения
Компонент	Веб-интерфейс API
Этап SDL	Сборка
Применимые технологии	Универсальные, MVC 5
Атрибуты	N/A, поставщик удостоверений — ADFS, поставщик удостоверений — идентификатор Microsoft Entra
Ссылки	Проверка подлинности и авторизация в веб-API ASP.NET
Шаги	Сведения о роли для пользователей приложения могут быть производными от идентификатора Microsoft Entra ID или утверждений ADFS, если приложение использует их в качестве поставщика удостоверений или само приложение может предоставить его. В каждом из этих случаев реализация настраиваемой авторизации должна проверять сведения о роли пользователя. Сведения о роли для пользователей приложения могут быть производными от идентификатора Microsoft Entra ID или утверждений ADFS, если приложение использует их в качестве поставщика удостоверений или само приложение может предоставить его. В каждом из этих случаев реализация настраиваемой авторизации должна проверять сведения о роли пользователя.

Пример

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class ApiAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
        public async override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
        {
            if (actionContext == null)
            {
                throw new Exception();
            }

            if (!string.IsNullOrEmpty(base.Roles))
            {
                bool isAuthorized = ValidateRoles(actionContext);
                if (!isAuthorized)
                {
                    HandleUnauthorizedRequest(actionContext);
                }
            }

            base.OnAuthorization(actionContext);
        }

public bool ValidateRoles(actionContext)
{
   //Authorization logic here; returns true or false
}

}

Для всех контроллеров и методов действий, которым требуется защита, необходимо добавить указанный выше атрибут.

[ApiAuthorize]
public class CustomController : ApiController
{
     //Application code goes here
}

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

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

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

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