Что такое токен безопасности и какова его роль в модели безопасности Windows

Обновлено: 21.11.2024

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

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

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

Какова реальность новых сетевых технологий? Здесь эксперты определяют риски — реальные или предполагаемые — и преимущества, которые они несут .

Сетевые архитектуры 4G и 5G имеют некоторые существенные различия. Посмотрите, чем отличаются две технологии и что нового .

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

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

Эксперты высоко оценивают недавно предложенное Комиссией по ценным бумагам и биржам США правило раскрытия информации о климатических рисках, которое требует от компаний выявлять климатические риски .

Недавнее мероприятие Accenture Technology Vision подчеркнуло трансформационные возможности виртуальных миров, а также указало на .

ИТ-администраторам, рассматривающим возможность перехода на Windows 11, следует узнать, как функции версии Enterprise могут помочь их .

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

Администраторам настольных компьютеров следует обратить внимание на собственные функции безопасности и архитектуру Windows 10, чтобы установить базовый уровень настольных компьютеров.

Nvidia запустила облачную версию своей платформы Omniverse для 3D-моделирования. Компания также представила Omniverse .

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

Чтобы добиться высокой доступности и отказоустойчивости в AWS, ИТ-администраторы должны сначала понять различия между двумя моделями.

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

Хакеры, действующие под лозунгом Anonymous, утверждают, что украли более 35 000 конфиденциальных файлов из Центрального банка .

Мобильная частная сеть Smart Sound Connect Marine 5G станет первым в мире испытательным стендом 5G, ориентированным на морские суда, в британском городе .

Модель безопасности Windows основана на защищаемых объектах. Каждый компонент операционной системы должен обеспечивать безопасность объектов, за которые он отвечает. Поэтому драйверы должны обеспечивать безопасность своих устройств и объектов устройств.

В этом разделе кратко изложено, как модель безопасности Windows применяется к драйверам режима ядра.

Модель безопасности Windows

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

Для каждого типа объекта общие права на чтение, запись и выполнение сопоставляются с подробными правами для конкретного объекта. Например, для файлов и каталогов возможные права включают право на чтение или запись файла или каталога, право на чтение или запись расширенных атрибутов файла, право на просмотр каталога и право на запись дескриптора безопасности объекта.< /p>

Модель безопасности включает следующие концепции:

Идентификаторы безопасности (SID)
Токены доступа
Дескрипторы безопасности
Списки контроля доступа (ACL)
Привилегии

Идентификаторы безопасности (SID)

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

Идентификаторы безопасности выдаются органом власти, например операционной системой или сервером домена. Некоторые SID хорошо известны и имеют имена, а также идентификаторы. Например, SID S-1-1-0 идентифицирует всех (или весь мир).

Токены доступа

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

По умолчанию система использует первичный токен доступа для процесса всякий раз, когда поток процесса взаимодействует с защищаемым объектом. Однако поток может олицетворять учетную запись клиента. Когда поток олицетворяет себя, у него есть маркер олицетворения в дополнение к его собственному первичному маркеру.Маркер олицетворения описывает контекст безопасности учетной записи пользователя, которую олицетворяет поток. Олицетворение особенно распространено при обработке удаленных вызовов процедур (RPC).

Маркер доступа, описывающий ограниченный контекст безопасности для потока или процесса, называется маркером ограниченного доступа. Идентификаторы безопасности в токенах с ограниченным доступом могут быть установлены только для отказа в доступе, а не для разрешения доступа к защищаемым объектам. Кроме того, токен может описывать ограниченный набор общесистемных привилегий. SID и идентификатор пользователя остаются прежними, но права доступа пользователя ограничены, пока процесс использует ограниченный токен. Функция CreateRestrictedToken создает токен с ограниченным доступом.

Дескрипторы безопасности

Каждый именованный объект Windows имеет дескриптор безопасности; некоторые безымянные объекты тоже. Дескриптор безопасности описывает SID владельца и группы для объекта вместе с его ACL.

Дескриптор безопасности объекта обычно создается функцией, которая создает объект. Когда драйвер вызывает подпрограмму IoCreateDevice или IoCreateDeviceSecure для создания объекта устройства, система применяет дескриптор безопасности к созданному объекту устройства и устанавливает ACL для объекта. Для большинства устройств списки управления доступом указываются в файле информации об устройстве (INF).

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

Списки контроля доступа

Списки управления доступом (ACL) обеспечивают детальный контроль над доступом к объектам. ACL является частью дескриптора безопасности для каждого объекта.

Каждый ACL содержит ноль или более записей управления доступом (ACE). Каждая запись ACE, в свою очередь, содержит один SID, который идентифицирует пользователя, группу или компьютер, а также список прав, которые запрещены или разрешены для этого SID.

ACL для объектов устройств

Список управления доступом для объекта устройства можно задать одним из трех способов:

Установите дескриптор безопасности по умолчанию для своего типа устройства.
Создается программно функцией RtlCreateSecurityDescriptor и устанавливается функцией RtlSetDaclSecurityDescriptor.
Указывается на языке определения дескрипторов безопасности (SDDL) в INF-файле устройства или в вызове процедуры IoCreateDeviceSecure.

Все драйверы должны использовать SDDL в INF-файле для указания ACL для своих объектов устройств.

SDDL — это расширяемый язык описания, который позволяет компонентам создавать списки управления доступом в строковом формате. SDDL используется как в пользовательском режиме, так и в режиме ядра. На следующем рисунке показан формат строк SDDL для объектов устройств.

Значение Access указывает тип разрешенного доступа. Значение SID указывает идентификатор безопасности, определяющий, к кому применяется значение доступа (например, к пользователю или группе).

Например, следующая строка SDDL разрешает Системе (SY) доступ ко всему, а всем остальным (WD) — только чтение:

Заголовочный файл wdmsec.h также содержит набор предопределенных строк SDDL, подходящих для объектов устройств. Например, файл заголовка определяет SDDL_DEVOBJ_SYS_ALL_ADM_RWX_WORLD_RWX_RES_RWX следующим образом:

Первый сегмент этой строки позволяет ядру и операционной системе (SY) полностью контролировать устройство. Второй сегмент позволяет любому члену встроенной группы администраторов (BA) получить доступ ко всему устройству, но не изменять ACL. Третий сегмент позволяет всем (WD) читать или записывать на устройство, а четвертый сегмент предоставляет такие же права недоверенному коду (RC). Драйверы могут использовать предопределенные строки как есть или в качестве моделей для строк, специфичных для объекта устройства.

Все объекты устройств в стеке должны иметь одинаковые списки управления доступом. Изменение списков ACL для одного объекта устройства в стеке приводит к изменению списков ACL для всего стека устройств.

Подпрограмма IoCreateDeviceSecure поддерживает подмножество строк SDDL, в которых используются предопределенные идентификаторы безопасности, такие как WD и SY. API пользовательского режима и файлы INF поддерживают полный синтаксис SDDL.

Проверки безопасности с помощью ACL

Когда процесс запрашивает доступ к объекту, проверки безопасности сравнивают списки управления доступом для объекта с SID в маркере доступа вызывающего объекта.

Система сравнивает ACE в строгом нисходящем порядке и останавливается на первом подходящем совпадении. Таким образом, при создании ACL вы всегда должны помещать ACE отказа выше соответствующих ACE предоставления. В следующих примерах показано, как происходит сравнение.

Пример 1. Сравнение ACL с токеном доступа

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

Пример файла ACL

Разрешение	SID	Доступ
Разрешить	Учет	Записать, удалить
Разрешить	Продажи	Добавить
Запретить	Разрешено	Добавить, записать, удалить
Разрешить	Все	Читать

У этого ACL есть четыре элемента управления доступом, которые относятся конкретно к группам Accounting, Sales, Legal и Everyone.

Далее предположим, что токен доступа для запрашивающего процесса содержит SID для одного пользователя и трех групп в следующем порядке:

Групповой учет (S-1-5-22…)

Юридический отдел группы (S-1-5-23…)

Группировать всех (S-1-1-0)

При сравнении файла ACL с токеном доступа система сначала ищет ACE для пользователя Jim в файле ACL. Ничего не появляется, поэтому затем он ищет ACE для группы учета. Как показано в предыдущей таблице, ACE для группы Accounting появляется в качестве первой записи в ACL файла, поэтому процессу Джима предоставляется право на запись или удаление файла, и сравнение останавливается. Если бы ACE для группы Legal вместо этого предшествовала ACE для группы Accounting в ACL, процессу было бы отказано в доступе к записи, добавлению и удалению файла.

Пример 2. Сравнение ACL с токеном с ограниченным доступом

Система сравнивает список ACL с токеном с ограничениями так же, как сравнивает списки в токене, доступ к которому не ограничен. Однако SID отказа в токене с ограниченным доступом может соответствовать только элементу управления доступом Deny ACE в ACL.

В примере 2 показано, как система сравнивает ACL файла с токеном с ограниченным доступом. Предположим, что файл имеет тот же ACL, что и в предыдущей таблице. Однако в этом примере у процесса есть токен с ограниченным доступом, который содержит следующие идентификаторы безопасности:

Пользователь Джим (S-1-5-21…) Запретить

Групповой учет (S-1-5-22…) Запретить

Юридическая группа (S-1-5-23…) Запретить

Группировать всех (S-1-1-0)

В ACL файла нет SID Джима, поэтому система переходит к SID группы учета. Хотя в ACL файла есть ACE для группы Accounting, этот ACE разрешает доступ; поэтому он не соответствует SID в токене ограниченного процесса, который запрещает доступ. В результате система переходит к SID юридической группы. ACL для файла содержит ACE для юридической группы, которая запрещает доступ, поэтому процесс не может записывать, добавлять или удалять файл.

Привилегии

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

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

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

Сценарий модели безопасности Windows: создание файла

Система использует конструкции безопасности, описанные в модели безопасности Windows, всякий раз, когда процесс создает дескриптор файла или объекта.

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

Приложение пользовательского режима вызывает функцию CreateFile, передавая допустимое имя файла Microsoft Win32.
Kernel32.dll пользовательского режима передает запрос Ntdll.dll, который преобразует имя Win32 в имя файла Microsoft Windows NT.
Ntdll.dll вызывает функцию NtCreateFile с именем файла Windows. В Ntoskrnl.exe диспетчер ввода-вывода обрабатывает NtCreateFile.
Диспетчер ввода-вывода переупаковывает запрос в вызов диспетчера объектов.
Диспетчер объектов разрешает символические ссылки и гарантирует, что у пользователя есть права на обход пути, по которому будет создан файл. Дополнительные сведения см. в разделе Проверки безопасности в диспетчере объектов.
Диспетчер объектов вызывает системный компонент, которому принадлежит базовый тип объекта, связанный с запросом. Для запроса на создание файла этим компонентом является диспетчер ввода-вывода, которому принадлежат объекты устройств.
Диспетчер ввода-вывода сравнивает дескриптор безопасности объекта устройства с токеном доступа процесса пользователя, чтобы убедиться, что у пользователя есть необходимый доступ к устройству. Дополнительную информацию см. в разделе Проверки безопасности в диспетчере ввода-вывода.
Если пользовательский процесс имеет требуемый доступ, диспетчер ввода-вывода создает дескриптор и отправляет запрос IRP_MJ_CREATE драйверу для устройства или файловой системы.
При необходимости водитель выполняет дополнительные проверки безопасности. Например, если в запросе указан объект в пространстве имен устройства, драйвер должен убедиться, что у вызывающего объекта есть необходимые права доступа.Дополнительную информацию см. в разделе Проверки безопасности в драйвере.

Проверки безопасности в диспетчере объектов

Ответственность за проверку прав доступа принадлежит компоненту самого высокого уровня, который может выполнять такие проверки. Если диспетчер объектов может проверить права доступа вызывающей стороны, он это делает. Если нет, диспетчер объектов передает запрос компоненту, ответственному за базовый тип объекта. Этот компонент, в свою очередь, проверяет доступ, если может; если это невозможно, он передает запрос компоненту еще более низкого уровня, например драйверу.

Диспетчер объектов проверяет списки управления доступом на предмет простых типов объектов, таких как события и мьютексы. Для объектов, у которых есть пространство имен, владелец типа выполняет проверки безопасности. Например, диспетчер ввода-вывода считается владельцем типа для объектов устройств и файловых объектов. Если диспетчер объектов находит имя объекта устройства или файлового объекта при анализе имени, он передает это имя диспетчеру ввода-вывода, как в представленном выше сценарии создания файла. Затем I/O Manager проверяет права доступа, если это возможно. Если имя указывает объект в пространстве имен устройства, диспетчер ввода-вывода, в свою очередь, передает имя драйверу устройства (или файловой системы), и этот драйвер отвечает за проверку запрошенного доступа.

Проверки безопасности в диспетчере ввода-вывода

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

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

Когда диспетчер ввода-вывода создает объект, он преобразует общие режимы доступа Win32 в права, специфичные для объекта. Например, к файлам и каталогам применяются следующие права:

Режим доступа Win32	Права для конкретных объектов
GENERIC_READ	ReadData
GENERIC_WRITE	WriteData
GENERIC_EXECUTE	ReadAttributes
GENERIC_ALL	Все

Чтобы создать файл, процесс должен иметь права доступа к родительским каталогам в целевом пути. Например, чтобы создать \Device\CDROM0\Directory\File.txt, процесс должен иметь право на обход \Device, \Device\CDROM0 и \Device\CDROM0\Directory. Диспетчер ввода-вывода проверяет только права доступа для этих каталогов.

Диспетчер ввода-вывода проверяет права обхода при анализе имени файла. Если имя файла является символической ссылкой, диспетчер ввода-вывода преобразует его в полный путь, а затем проверяет права на обход, начиная с корня. Например, предположим, что символическая ссылка \DosDevices\D соответствует имени устройства Windows NT \Device\CDROM0. Процесс должен иметь права доступа к каталогу \Device.

Проверки безопасности в драйвере

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

С драйверами WDM диспетчер ввода-вывода не выполняет проверки безопасности пространства имен, если только не был создан объект устройства с указанием FILE_DEVICE_SECURE_OPEN. Если FILE_DEVICE_SECURE_OPEN не установлен, драйвер отвечает за обеспечение безопасности своего пространства имен. Дополнительные сведения см. в разделах Управление доступом к пространству имен устройств и Защита объектов устройств.

Для драйверов WDF всегда устанавливается флаг FILE_DEVICE_SECURE_OPEN, чтобы перед разрешением доступа приложения к любым именам в пространстве имен устройства выполнялась проверка дескриптора безопасности устройства. Дополнительные сведения см. в разделе Управление доступом к устройствам в драйверах KMDF.

Границы безопасности Windows

Драйверы, взаимодействующие друг с другом и с вызывающими абонентами пользовательского режима с разными уровнями привилегий, могут рассматриваться как пересекающие границу доверия. Граница доверия — это любой путь выполнения кода, который пересекает процесс с более низким уровнем привилегий в процесс с более высоким уровнем привилегий.

Чем выше несоответствие в уровнях привилегий, тем интереснее граница для злоумышленников, которые хотят выполнить атаки, такие как атака с повышением привилегий, против целевого драйвера или процесса.

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

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

На этой диаграмме показаны три драйвера ядра и два приложения: одно в контейнере приложений и одно приложение, работающее с правами администратора. Красными линиями показаны примерные границы доверия.

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

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

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

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

Токен доступа. Токен доступа – это токен безопасности, выдаваемый сервером авторизации в рамках потока OAuth 2.0. Он содержит информацию о пользователе и ресурсе, для которого предназначен токен. Эта информация может использоваться для доступа к веб-API и другим защищенным ресурсам. Маркеры доступа проверяются ресурсами для предоставления доступа к клиентскому приложению. Чтобы узнать больше о том, как платформа Microsoft Identity выдает маркеры доступа, см. раздел Маркеры доступа.

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

Идентификационный токен. Идентификационные токены отправляются клиентскому приложению как часть потока OpenID Connect. Их можно отправлять вместе с токеном доступа или вместо него. Токены ID используются клиентом для аутентификации пользователя. Чтобы узнать больше о том, как платформа Microsoft Identity выдает токены идентификаторов, см. раздел Токены идентификаторов.

В этой статье обсуждаются токены безопасности, используемые протоколами OAuth2 и OpenID Connect. Многие корпоративные приложения используют SAML для аутентификации пользователей. Дополнительные сведения об утверждениях SAML см. в справочнике по токену SAML Azure Active Directory.

Проверить токены безопасности

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

Токены действительны только в течение ограниченного периода времени. Обычно сервер авторизации предоставляет пару токенов, например:

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

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

Веб-токены и утверждения JSON

Платформа Microsoft Identity реализует токены безопасности в виде веб-токенов JSON (JWT), которые содержат утверждения. Поскольку JWT используются в качестве токенов безопасности, эта форма аутентификации иногда называется JWT-аутентификация.

Утверждение предоставляет утверждения об одном объекте, таком как клиентское приложение или владелец ресурса, другому объекту, например серверу ресурсов. Заявка также может называться заявкой JWT или заявкой JSON Web Token.

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

Приложения могут использовать утверждения для различных задач, например:

Проверьте токен.
Определить арендатора субъекта токена.
Отображать информацию о пользователе.
Определить авторизацию субъекта.

Заявка состоит из пар "ключ-значение", которые предоставляют такую информацию, как:

Сервер токенов безопасности, создавший токен.
Дата создания токена.
Тема (например, пользователь, за исключением демонов).
Аудитория, то есть приложение, для которого был создан токен.
Приложение (клиент), запросившее токен. В случае веб-приложений это приложение может совпадать с аудиторией.

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

Как каждый поток генерирует токены и коды

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

th> < /tr> < td>Токен обновления

Поток	Требуется	Токен ID	Токен доступа	Токен обновления
Поток кода авторизации	x	x	x	x
Неявный поток	x	x
Гибридный поток OIDC	x	x
Выкуп токена обновления	x	x	x
От имени потока	Токен доступа	x	x	x
Учетные данные клиента	x (только приложение)

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

Дальнейшие шаги

Дополнительные сведения об аутентификации и авторизации на платформе Microsoft Identity см. в следующих статьях:

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

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

Идентификатор безопасности (SID) для учетной записи пользователя
SID для групп, членом которых является пользователь
SID для входа, определяющий текущий сеанс входа
Список привилегий, которыми обладает пользователь или группы пользователей.
SID владельца
SID для основной группы
Список DACL по умолчанию, который система использует, когда пользователь создает защищаемый объект без указания дескриптора безопасности
Источник токена доступа
Является ли токен основным или токеном олицетворения
Необязательный список ограничивающих SID.
Текущие уровни олицетворения
Другая статистика

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

Используйте функцию OpenProcessToken, чтобы получить дескриптор основного токена процесса. Используйте функцию OpenThreadToken, чтобы получить дескриптор токена олицетворения потока. Дополнительные сведения см. в разделе Олицетворение.

Вы можете использовать следующие функции для управления токенами доступа.

td>

Функция	Описание
AdjustTokenGroups	Изменяет информацию о группе в маркере доступа.
AdjustTokenPrivileges	Включает или отключает привилегии в маркере доступа. Он не предоставляет новые привилегии и не отменяет существующие.
CheckTokenMembership	Определяет, включен ли указанный SID в указанном токене доступа.
CreateRestrictedToken	Создает новый токен, который является ограниченной версией существующего токена. Ограниченный токен может содержать отключенные SID, удаленные привилегии и список ограниченных SID.
DuplicateToken	Создает новый токен олицетворения, дублирующий существующий токен. .
DuplicateTokenEx	Создает новый первичный токен или токен олицетворения, который дублирует существующий токен.
GetTokenInformation	Получает информацию о токене.
IsTokenRestricted	Определяет, есть ли у токена список ограничивающих SID.
OpenProcessToken	Получает дескриптор основного токена доступа для процесса.
OpenThreadToken	Получает дескриптор маркера доступа к олицетворению для потока.
SetThreadToken	Назначает или удаляет маркер олицетворения для потока.
SetTokenInformation	Изменяет владельца токена, основную группу или список DACL по умолчанию.

Функции токена доступа используют следующие структуры для описания частей токена доступа.

Читайте также: