Методы проверки подлинности

В этом разделе представлен обзор методов проверки подлинности клиента, используемых Шлюз Microsoft Forefront Threat Management.

Forefront TMG поддерживает следующие типы проверки подлинности HTTP:

• обычная проверка подлинности
• проверка подлинности Digest и WDigest
• встроенная проверка подлинности Windows

Обычная проверка подлинности

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

1. Пользователю предлагается ввести имя и пароль для входа в учетную запись Windows.
2. Forefront TMG получает HTTP-запрос с учетными данными пользователя и подтверждает их с помощью определенного сервера проверки подлинности (RADIUS или Active Directory, LDAP-сервер используется только для входящих запросов).
3. Для исходящих запросов веб-прокси Forefront TMG подтверждает учетные данные пользователя и затем определяет правила доступа. Для входящих запросов Forefront TMG использует учетные данные для проверки подлинности на опубликованном веб-сервере в соответствии с настроенным методом делегирования. Веб-сервер должен быть настроен на применение схемы проверки подлинности, которая соответствует методу делегирования, используемому Forefront TMG. Текстовый пароль кодируется с помощью Base64 до того, как будет переслан по сети, но это не шифрование, и если пароль будет перехвачен в сети анализатором сетевых пакетов, неавторизованные пользователи могут раскодировать и повторно использовать пароль.

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

Проверка подлинности Digest и WDigest

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

Проверка подлинности Digest использует протокол HTTP 1.1, как определено в RFC 2617. Этот протокол поддерживается не всеми обозревателями. Если обозреватель, не поддерживающий протокол HTTP 1.1, запрашивает файл при включенной проверке подлинности Digest, запрос отклоняется. Проверка подлинности Digest может использоваться только в доменах Windows.

Проверка подлинности Digest успешно применима, если на контроллере домена в службе Active Directory хранится обратимая зашифрованная (текстовая) копия запроса пароля пользователя. Чтобы разрешить хранение паролей в незашифрованном текстовом виде, пользователю нужно активировать настройку Хранить пароль с использованием обратимого шифрования на вкладке Учетная запись Также пользователь может включить данную функцию, установив соответствующую групповую политику. После этого пользователю нужно установить новый пароль, чтобы активировать данную функцию, поскольку прежний пароль не может быть определен.

WDigest, обновленная форма проверки подлинности Digest, используется, если Forefront TMG установлен в домене Windows Server 2008. Проверка подлинности WDigest не требует, чтобы в службе Active Directory хранилась обратимая зашифрованная копия пароля пользователя.

Проверка подлинности Digest и WDigest осуществляется следующим образом:

1. Клиент делает запрос.
2. Forefront TMG отказывает в доступе и предлагает клиенту ввести имя пользователя и пароль для входа в учетную запись Windows. Примечание. При использовании WDigest имя пользователя и имя домена чувствительны к регистру и должны указываться точно так же, как они отображены в службе Active Directory. Кроме этого для WDigest требуется ввести значение для пути доступа к URL. Например, запрос пользователя http://host.domain.tld не обрабатывается, поскольку отсутствует путь доступа к URL.
3. Учетные данные пользователя проходят одностороннюю процедуру, наименование которой известно как хэширование На выходе получается зашифрованный хэш или профиль сообщения. В него добавляются значения для идентификации пользователя, компьютера пользователя и домена. Чтобы исключить применение пользователем аннулированного пароля, добавляется отметка времени. Это явное преимущество перед обычной проверкой подлинности, поскольку снижается вероятность перехвата и использования пароля неавторизованным пользователем.

Встроенная проверка подлинности (NTLM)

Встроенная проверка подлинности Windows использует методы проверки подлинности NTLM, Kerberos и Negotiate. Это более безопасные формы проверки подлинности, поскольку имя пользователя и пароль хэшируются до отправления их по сети. Если включена проверка подлинности NTLM, Kerberos или Negotiate, обозреватель пользователя подтверждает пароль при помощи обмена криптографическими данными с сервером Forefront TMG и хэширования.

Ниже описывается, как происходит проверка подлинности клиента при встроенной проверке подлинности Windows.

1. В зависимости от настроек обозревателя проверка подлинности может не запрашивать изначально имя пользователя и пароль. Если изначально не удается идентифицировать пользователя, обозреватель запрашивает имя пользователя и пароль для входа в учетную запись Windows, которые он обрабатывает с помощью встроенной проверки подлинности Windows. Веб-обозреватель продолжает запрашивать имя пользователя и пароль до тех пор, пока пользователь не введет достоверные сведения или не закроет диалоговое окно с запросом. Имя пользователя необходимо вводить в формате:
   домен\имя_пользователя
2. Если изначально не удается идентифицировать пользователя, обозреватель запрашивает имя пользователя и пароль для входа в учетную запись Windows, которые он обрабатывает с помощью встроенной проверки подлинности Windows.
3. Forefront TMG продолжает запрашивать имя пользователя и пароль до тех пор, пока пользователь не введет достоверные сведения или не закроет диалоговое окно с запросом.

Примечание.

• Forefront TMG обращается к серверу Active Directory каждый раз, когда требуется проверка подлинности NTLM. Поэтому пользователю рекомендуется создать защищенную сеть для Active Directory и Forefront TMG, чтобы исключить возможность доступа к обмену данными со стороны пользователей (внешних и внутренних).
• Поскольку проверка подлинности для внешних пользователей применяет метод NTLM, пользователям рекомендуется использовать SSL-шифрование трафика между Forefront TMG и клиентом. Проверка подлинности NTLM осуществляется для каждого соединения, а шифрование предупреждает повторное использование соединений унаследованными устройствами прокси в Интернете.

Проверка подлинности на основе форм в Forefront TMG может использоваться для входящих запросов на опубликованные веб-серверы. Существует три типа проверки подлинности на основе форм:

• Форма пароля — пользователь вводит имя пользователя и пароль в форму. Этот тип учетных данных необходим для проверки подлинности с помощью методов Active Directory, LDAP и RADIUS
• Форма кода доступа — пользователь вводит имя пользователя и код доступа в форму. Этот тип учетных данных необходим для проверки одноразовых паролей методами SecurID и RADIUS.
• Форма Код доступа/Пароль — пользователь вводит имя пользователя и код доступа и имя пользователя и пароль. Имя пользователя и код доступа используются при проверке подлинности для доступа к Forefront TMG с помощью методов проверки подлинности одноразовых паролей SecurID или RADIUS, а имя пользователя и пароль — при методе делегирования.

Проверка подлинности сертификата клиента не поддерживается для исходящих веб-запросов. Пользователь может использовать сертификат клиента для проверки подлинности Forefront TMG для доступа к вышестоящему прокси-серверу. Дополнительные сведения см. в разделе Формирование цепочки веб-прокси.

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

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

Проверка подлинности и шифрование

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

Методы проверки подлинности

Устройство Brother поддерживает следующие методы:

•	Открытая система Беспроводным устройствам разрешено подключаться к сети без проверки подлинности.
•	Секретный предопределенный ключ совместно используется всеми устройствами, которые получают доступ к беспроводной сети. Беспроводное устройство Brother в качестве предопределенного ключа использует ключи WEP.
•	Подключает предварительный ключ для защищенного доступа Wi-Fi® (WPA-PSK/WPA2-PSK), который позволяет беспроводному устройству Brother ассоциироваться с точками доступа с использованием TKIP для WPA-PSK или AES для WPA-PSK и WPA2-PSK (режим «WPA-личный»).

Методы шифрования

Шифрование используется для защиты данных, посылаемых по беспроводной сети. Беспроводное устройство Brother поддерживает следующие методы шифрования:

•	Нет Метод шифрования не используется.
•	При использовании WEP (Wired Equivalent Privacy) данные отправляются и принимаются при помощи защитного ключа.
•	TKIP (Temporal Key Integrity Protocol, протокол целостности временного ключа) обеспечивает смешивание ключей по пакетам, проверку целостности сообщения и механизм повторного создания ключей.
•	AES (Advanced Encryption Standard, усовершенствованный стандарт криптографической защиты) это одобренный Wi-Fi® стандарт надежного шифрования.

Сетевой ключ

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

•

Открытая система/Общий ключ с WEP Этот ключ представляет собой 64- или 128-битовое значение, которое должно вводиться в формате ASCII или шестнадцатеричном формате. •  64 (40) бит ASCII: 5 букв, например «WSLAN» (с учетом регистра). •  64 (40) бит шестнадцатеричный: 10 знаков шестнадцатеричных данных, например «71f2234aba». •  128 (104) бит ASCII: 13 букв, например «Wirelesscomms» (с учетом регистра). •  128 (104) бит шестнадцатеричный: 26 знаков шестнадцатеричных данных, например «71f2234ab56cd709e5412aa3ba».

•

WPA-PSK/WPA2-PSK и TKIP или AES Использует предварительный ключ (Pre-Shared Key, PSK), который имеет длину не менее 8 и не более 63 знаков.

Проверка подлинности Вики

Аутентифика́ция (англ. authentication < греч. αὐθεντικός

[authentikos] «реальный, подлинный» < αὐτός [autos] «сам; он самый») — процедура проверки подлинности, например:

В русском языке термин применяется, в основном, в области информационных технологий.

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

Аутентификацию не следует путать с авторизацией (процедурой предоставления субъекту определённых прав) и идентификацией (процедурой распознавания субъекта по его идентификатору).

История[ | код]

С древних времён перед людьми стояла довольно сложная задача — убедиться в достоверности важных сообщений. Придумывались речевые пароли, сложные печати. Появление методов аутентификации с применением механических устройств сильно упрощало задачу, например, обычный замок и ключ были придуманы очень давно. Пример системы аутентификации можно увидеть в старинной сказке «Приключения Али́-Бабы́ и сорока разбойников». В этой сказке говорится о сокровищах, спрятанных в пещере. Пещера была загорожена камнем. Отодвинуть его можно было только с помощью уникального речевого пароля: «Сим-Сим, откройся!».

В настоящее время в связи с обширным развитием сетевых технологий автоматическая аутентификация используется повсеместно.

Стандарты[ | код]

Документы, определяющие стандарты аутентификации

ГОСТ Р ИСО/МЭК 9594-8-98 — Основы аутентификации[ | код]

Настоящий стандарт:

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

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

FIPS 113 — COMPUTER DATA AUTHENTICATION[ | код]

Настоящий стандарт устанавливает Data Authentication Algorithm(DAA), который может быть использован для обнаружения несанкционированных изменений данных, как преднамеренных, так и случайных, стандарт основан на алгоритме, указанном в Data Encryption Standard(DES) Federal Information Processing Standards Publication(FIPS PUB) 46, и совместим как с Department of the Treasury’s Electronic Funds and Security Transfer Policy and the American National Standards Institute(ANSI) так и с Standard for Financial Institution Message Authentication.

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

Элементы системы аутентификации[ | код]

В любой системе аутентификации обычно можно выделить несколько элементов:

• субъект, который будет проходить процедуру
• характеристика субъекта — отличительная черта
• хозяин системы аутентификации, несущий ответственность и контролирующий её работу
• сам механизм аутентификации, то есть принцип работы системы
• механизм управления доступом, предоставляющий определённые права доступа субъекту

Элемент аутентификации	Пещера 40 разбойников	Регистрация в системе	Банкомат
Субъект	Человек, знающий пароль	Авторизованный пользователь	Держатель банковской карты
Характеристика	Пароль «Сим-Сим, откройся!»	Тайный пароль	Банковская карта и персональный идентификатор
Хозяин системы	40 разбойников	Предприятие, которому принадлежит система	Банк
Механизм аутентификации	Волшебное устройство, реагирующее на слова	Программное обеспечение, проверяющее пароль	Программное обеспечение, проверяющее карту и персональный идентификатор
Механизм управления доступом	Механизм, отодвигающий камень от входа в пещеру	Процесс регистрации, управления доступом	Разрешение на выполнение банковских действий

Факторы аутентификации[ | код]

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

• Нечто, что нам известно, например, какая-либо секретная информация. Это тайные сведения, которыми должен обладать только авторизованный субъект. Секретом может быть некая фраза или пароль, например в виде устного сообщения, текстового представления, комбинации для замка или личного идентификационного номера (PIN). Парольный механизм может быть довольно легко воплощён и имеет низкую стоимость. Но имеет существенные недостатки: сохранить пароль в тайне зачастую бывает сложно, злоумышленники постоянно придумывают новые способы кражи, взлома и подбора пароля (см. бандитский криптоанализ, метод грубой силы). Это делает парольный механизм слабозащищённым.
• Нечто, чем мы обладаем, например, какой-либо уникальный физический объект. Здесь важно обстоятельство обладания субъектом каким-то неповторимым предметом. Это может быть личная печать, ключ от замка, для компьютера это файл данных, содержащих характеристику. Характеристика часто встраивается в особое устройство аутентификации, например, пластиковая карта, смарт-карта. Для злоумышленника заполучить такое устройство становится более сложно, чем взломать пароль, а субъект может сразу же сообщить в случае кражи устройства. Это делает данный метод более защищённым, чем парольный механизм, однако стоимость такой системы более высокая.
• Нечто, что является неотъемлемой частью нас самих — биометрика. Характеристикой является физическая особенность субъекта. Это может быть портрет, отпечаток пальца или ладони, голос или особенность глаза. С точки зрения субъекта, данный способ является наиболее простым: не надо ни запоминать пароль, ни переносить с собой устройство аутентификации. Однако биометрическая система должна обладать высокой чувствительностью, чтобы подтверждать авторизованного пользователя, но отвергать злоумышленника со схожими биометрическими параметрами. Также стоимость такой системы довольно велика. Но, несмотря на свои недостатки, биометрика остается довольно перспективным фактором.

Способы аутентификации[ | код]

Аутентификация при помощи электронной подписи[ | код]

Федеральный закон от 06.04.2011 N 63-ФЗ «Об электронной подписи» (с изменениями) предусматривает следующие виды электронной подписи:

• Простая электронная подпись — электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом.
• Неквалифицированная электронная подпись — электронная подпись, которая:

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

• Квалифицированная электронная подпись — электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:

1. ключ проверки электронной подписи указан в квалифицированном сертификате;
2. для создания и проверки электронной подписи используются средства электронной подписи, получившие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.

Аутентификация по паролям[ | код]

• Аутентификация по многоразовым паролям
• Аутентификация по одноразовым паролям

Аутентификация по многоразовым паролям[ | код]

Форма ввода связки логин-пароля

Один из способов аутентификации в компьютерной системе состоит во вводе вашего пользовательского идентификатора, в просторечии называемого «логином» (англ. login — регистрационное имя пользователя, учётка) и пароля — неких конфиденциальных сведений. Достоверная (эталонная) пара логин-пароль хранится в специальной базе данных.

Простая аутентификация имеет следующий общий алгоритм:

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

Введённый субъектом пароль может передаваться в сети двумя способами:

• Незашифрованно, в открытом виде, на основе протокола парольной аутентификации (Password Authentication Protocol, PAP)
• С использованием шифрования SSL или TLS. В этом случае неповторимые данные, введённые субъектом, передаются по сети защищённо.

Защищённость[ | код]

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

Использование многоразовых паролей имеет ряд существенных недостатков. Во-первых, сам эталонный пароль или его хешированный образ хранятся на сервере аутентификации. Зачастую хранение пароля производится без криптографических преобразований, в системных файлах. Получив доступ к ним, злоумышленник легко доберётся до конфиденциальных сведений. Во-вторых, субъект вынужден запоминать (или записывать) свой многоразовый пароль. Злоумышленник может заполучить его, просто применив навыки социальной инженерии, без всяких технических средств. Кроме того, сильно снижается защищенность системы в случае, когда субъект сам выбирает себе пароль. Зачастую им оказывается какое-то слово или сочетание слов, присутствующие в словаре. В ГОСТ 28147-89 длина ключа составляет 256 бит (32 байта). При использовании генератора псевдослучайных чисел ключ обладает хорошими статистическими свойствами. Пароль же, который является, например, словом из словаря, можно свести к псевдослучайному числу длиной 16 бит, что короче ГОСТ-ового ключа в 16 раз. При достаточном количестве времени злоумышленник может взломать пароль простым перебором. Решением этой проблемы является использование случайных паролей или ограниченность по времени действия пароля субъекта, по истечении которого пароль необходимо поменять.

Базы учетных записей[ | код]

На компьютерах с ОС семейства UNIX базой является файл /etc/master.passwd (в дистрибутивах Linux обычно файл /etc/shadow, доступный для чтения только root), в котором пароли пользователей хранятся в виде хеш-функций от открытых паролей, кроме этого, в этом же файле хранится информация о правах пользователя. Изначально в Unix-системах пароль (в зашифрованном виде) хранился в файле /etc/passwd, доступном для чтения всем пользователям, что было небезопасно.

На компьютерах с операционной системой Windows NT/2000/XP/2003 (не входящих в домен Windows) такая база данных называется SAM (Security Account Manager — Диспетчер защиты учётных записей). База SAM хранит учётные записи пользователей, включающие в себя все данные, необходимые системе защиты для функционирования. Находится в каталоге %windir%\system32\config\.

В доменах Windows Server 2000/2003 такой базой является Active Directory.

Однако более надёжным способом хранения аутентификационных данных признано использование особых аппаратных средств (компонентов).

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

Аутентификация по одноразовым паролям[ | код]

Заполучив однажды многоразовый пароль субъекта, злоумышленник имеет постоянный доступ к взломанным конфиденциальным сведениям. Эта проблема решается применением одноразовых паролей (OTP — One Time Password). Суть этого метода — пароль действителен только для одного входа в систему, при каждом следующем запросе доступа — требуется новый пароль. Реализован механизм аутентификации по одноразовым паролям может быть как аппаратно, так и программно.

Технологии использования одноразовых паролей можно разделить на:

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

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

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

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

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

Аутентификация с помощью SMS[ | код]

Актуальность обеспечения безопасности мобильных средств коммуникации, например, ip-phone, стимулирует новые разработки в этой области. Среди них можно назвать аутентификацию с помощью SMS-сообщений.

Процедура такой аутентификации включает в себя следующие шаги:

1. Ввод имени пользователя и пароля
2. Сразу после этого PhoneFactor (служба безопасности) присылает одноразовый аутентификационный ключ в виде текстового SMS-сообщения.
3. Полученный ключ используется для аутентификации

Привлекательность данного метода заключается в том, что ключ получается не по тому каналу, по которому производится аутентификация (out-of-band), что практически исключает атаку типа «человек посередине». Дополнительный уровень безопасности может дать требование ввода PIN-кода мобильного средства.

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

Биометрическая аутентификация[ | код]

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

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

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

Наиболее используемые биометрические атрибуты и соответствующие системы[ | код]

• Отпечатки пальцев. Такие сканеры имеют небольшой размер, универсальны, относительно недороги. Биологическая повторяемость отпечатка пальца составляет 10⁻⁵ %. В настоящее время пропагандируются правоохранительными органами из-за крупных ассигнований в электронные архивы отпечатков пальцев.
• Геометрия руки. Соответствующие устройства используются, когда из-за грязи или травм трудно применять сканеры пальцев. Биологическая повторяемость геометрии руки около 2 %.
• Радужная оболочка глаза. Данные устройства обладают наивысшей точностью. Теоретическая вероятность совпадения двух радужных оболочек составляет 1 из 10⁷⁸.
• Термический образ лица. Системы позволяют идентифицировать человека на расстоянии до десятков метров. В комбинации с поиском данных по базе данных такие системы используются для опознания авторизованных сотрудников и отсеивания посторонних. Однако при изменении освещенности сканеры лица имеют относительно высокий процент ошибок.
• Распознавание по лицу. Системы на основе данного подхода позволяют идентифицировать персону в определенных условиях с погрешностью не более 3 %. В зависимости от метода позволяют идентифицировать человека на расстояниях от полуметра до нескольких десятков метров. Данный метод удобен тем, что он позволяет реализацию штатными средствами (веб-камера и т. п.). Более сложные методы требуют более изощренных устройств. Некоторые (не все) методы обладают недостатком подмены: можно провести идентификацию подменив лицо реального человека на его фотографию.
• Голос. Проверка голоса удобна для использования в телекоммуникационных приложениях. Необходимые для этого 16-разрядная звуковая плата и конденсаторный микрофон стоят менее 25 $. Вероятность ошибки составляет 2 — 5 %. Данная технология подходит для верификации по голосу по телефонным каналам связи, она более надежна по сравнению с частотным набором личного номера. Сейчас развиваются направления идентификации личности и его состояния по голосу — возбужден, болен, говорит правду, не в себе и т. д.
• Ввод с клавиатуры. Здесь при вводе, например, пароля отслеживаются скорость и интервалы между нажатиями.
• Подпись. Для контроля рукописной подписи используются дигитайзеры

В то же время биометрическая аутентификация имеет ряд недостатков:

1. Биометрический шаблон сравнивается не с результатом первоначальной обработки характеристик пользователя, а с тем, что пришло к месту сравнения. За время пути может много чего произойти.
2. База шаблонов может быть изменена злоумышленником.
3. Следует учитывать разницу между применением биометрии на контролируемой территории, под бдительным оком охраны, и в «полевых» условиях, когда, например, к устройству сканирования могут поднести муляж и т. п.
4. Некоторые биометрические данные человека меняются (как в результате старения, так и травм, ожогов, порезов, болезни, ампутации и т. д.), так что база шаблонов нуждается в постоянном сопровождении, а это создает определенные проблемы и для пользователей, и для администраторов.
5. Если у Вас крадут биометрические данные или их компрометируют, то это, как правило, на всю жизнь. Пароли, при всей их ненадежности, в крайнем случае можно сменить. Палец, глаз или голос сменить нельзя, по крайней мере быстро.
6. Биометрические характеристики являются уникальными идентификаторами, но их нельзя сохранить в секрете.

Аутентификация через географическое местоположение[ | код]

• Аутентификация посредством GPS
• Аутентификация, основанная на местоположении выхода в интернет

Аутентификация посредством GPS[ | код]

Новейшим направлением аутентификации является доказательство подлинности удаленного пользователя по его местонахождению. Данный защитный механизм основан на использовании системы космической навигации, типа GPS (Global Positioning System).

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

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

Аппаратура GPS проста и надежна в использовании и сравнительно недорога. Это позволяет её использовать в случаях, когда авторизованный удаленный пользователь должен находиться в нужном месте.

Аутентификация, основанная на местоположении выхода в интернет[ | код]

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

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

Многофакторная аутентификация[ | код]

В последнее время всё чаще применяется так называемая расширенная, или многофакторная, аутентификация. Она построена на совместном использовании нескольких факторов аутентификации. Это значительно повышает защищённость системы.

В качестве примера можно привести использование SIM-карт в мобильных телефонах. Субъект вставляет аппаратно свою карту (устройство аутентификации) в телефон и при включении вводит свой PIN-код (пароль).

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

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

Можно привести сравнительную таблицу:

Уровень риска	Требования к системе	Технология аутентификации	Примеры применения
Низкий	Требуется осуществить аутентификацию для доступа к системе, причём кража, взлом, разглашение конфиденциальных сведений не будут иметь значительных последствий	Рекомендуется минимальное требование — использование многоразовых паролей	Регистрация на портале в сети Интернет
Средний	Требуется осуществить аутентификацию для доступа к системе, причём кража, взлом, разглашение конфиденциальных сведений причинят небольшой ущерб	Рекомендуется минимальное требование — использование одноразовых паролей	Произведение субъектом банковских операций
Высокий	Требуется осуществить аутентификацию для доступа к системе, причём кража, взлом, разглашение конфиденциальных сведений причинят значительный ущерб	Рекомендуется минимальное требование — использование многофакторной аутентификации	Проведение крупных межбанковских операций руководящим аппаратом

Протоколы аутентификации[ | код]

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

Таким образом, можно выделить несколько семейств аутентификации:

Аутентификация пользователя на PC:

• Шифрованное имя (login)
• Password Authentication Protocol, PAP (связка логин-пароль)
• Карта доступа (USB с сертификатом, SSO)
• Биометрия (голос, отпечаток пальца/ладони/радужки глаза)

Аутентификация в сети:

В операционных системах семейства Windows NT 4 используется протокол NTLM (NT LAN Manager — Диспетчер локальной сети NT). А в доменах Windows 2000/2003 применяется гораздо более совершенный протокол Kerberos.

Аутентификация в Интернете[ | код]

Аутентификация требуется при доступе к таким сервисам как:

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

См. также[ | код]

Литература[ | код]

• Ричард Э. Смит. Аутентификация: от паролей до открытых ключей = Authentication: From Passwords to Public Keys First Edition. — М.: Вильямс, 2002. — С. 432. — ISBN 0-201-61599-1.
• под. редакцией А.А. Шелупанова, С.Л. Груздева, Ю.С. Нахаева. Аутентификация. Теория и практика обеспечения доступа к информационным ресурсам. = Authentication. Theory and practice of ensuring access to information resources.. — М.: Горячая линия – Телеком, 2009. — С. 552. — ISBN 978-5-9912-0110-0.
• Шнайер Б. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
• Linn J. Common Authentication Technology Overview,.
• Bellovin S. and M. Merritt. Limitations of the Kerberos Authentication System.
• Kaufman, C. Distributed Authentication Security Service (DASS).
• Anderson, B.,. TACACS User Identification Telnet Option. — December 1984.
• Tardo J. and K. Alagappan. SPX: Global Authentication Using Public Key Certificates. — М.California, 1991. — С. pp.232-244.
• А.А. Гладких, В.Е. Дементьев. Базовые принципы информационной безопасности вычислительных сетей.. — Ульяновск: УлГТУ, 2009. — С. 156.

Ссылки[ | код]

Процессы учетных данных

при проверке подлинности Windows

• 12.10.2016
• 26 минут на чтение

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2016

В этом справочном разделе для ИТ-специалистов описывается, как проверка подлинности Windows обрабатывает учетные данные.

Управление учетными данными Windows — это процесс, с помощью которого операционная система получает учетные данные от службы или пользователя и защищает эту информацию для будущего представления цели аутентификации.В случае компьютера, присоединенного к домену, целью аутентификации является контроллер домена. Учетные данные, используемые при аутентификации, представляют собой цифровые документы, которые связывают личность пользователя с некоторой формой доказательства подлинности, такой как сертификат, пароль или ПИН-код.

По умолчанию учетные данные Windows проверяются в базе данных диспетчера учетных записей безопасности (SAM) на локальном компьютере или в Active Directory на компьютере, присоединенном к домену, через службу Winlogon. Учетные данные собираются посредством пользовательского ввода в пользовательском интерфейсе входа в систему или программно через интерфейс прикладного программирования (API) для представления цели аутентификации.

Локальная информация о безопасности хранится в реестре под HKEY_LOCAL_MACHINE \ SECURITY . Сохраняемая информация включает параметры политики, значения безопасности по умолчанию и информацию об учетной записи, например, кэшированные учетные данные для входа. Здесь также хранится копия базы данных SAM, хотя она и защищена от записи.

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

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

Компоненты аутентификации для всех систем

Компонент	Описание
Вход в систему	Winlogon.exe — это исполняемый файл, отвечающий за управление безопасным взаимодействием с пользователем. Служба Winlogon инициирует процесс входа в систему для операционных систем Windows, передавая учетные данные, собранные в результате действий пользователя на безопасном рабочем столе (пользовательский интерфейс входа), в Local Security Authority (LSA) через Secur32.dll.
Вход в приложение	Вход в приложение или службу, не требующий интерактивного входа. Большинство процессов, инициированных пользователем, запускаются в пользовательском режиме с использованием Secur32.dll, тогда как процессы, инициируемые при запуске, например службы, выполняются в режиме ядра с помощью Ksecdd.sys. Дополнительные сведения о пользовательском режиме и режиме ядра см. В разделах Приложения и режим пользователя или Службы и режим ядра в этом разделе.
Secur32.dll	Несколько провайдеров аутентификации, которые составляют основу процесса аутентификации.
Lsasrv.dll	Служба сервера LSA, которая обеспечивает соблюдение политик безопасности и действует как менеджер пакетов безопасности для LSA. LSA содержит функцию согласования, которая выбирает протокол NTLM или Kerberos после определения того, какой протокол должен быть успешным.
Провайдеры поддержки безопасности	Набор провайдеров, которые могут индивидуально вызывать один или несколько протоколов аутентификации. Набор поставщиков по умолчанию может меняться с каждой версией операционной системы Windows, и можно писать собственные поставщики.
Netlogon.dll	Служба сетевого входа в систему выполняет следующие службы: — Поддерживает безопасный канал компьютера (не путать с Schannel) к контроллеру домена. — передает учетные данные пользователя через безопасный канал контроллеру домена и возвращает идентификаторы безопасности домена (SID) и права пользователя для пользователя. — публикует записи ресурсов службы в системе доменных имен (DNS) и использует DNS для преобразования имен в IP-адреса контроллеров домена. — Реализует протокол репликации на основе удаленного вызова процедур (RPC) для синхронизации основных контроллеров домена (PDC) и резервных контроллеров домена (BDC).
Samsrv.dll	Менеджер учетных записей безопасности (SAM), который хранит локальные учетные записи безопасности, обеспечивает соблюдение локально сохраненных политик и поддерживает API.
Реестр	Реестр содержит копию базы данных SAM, параметры локальной политики безопасности, значения безопасности по умолчанию и информацию об учетной записи, доступную только системе.

Этот раздел содержит следующие разделы:

Ввод учетных данных для входа пользователя

В Windows Server 2008 и Windows Vista архитектура графической идентификации и проверки подлинности (GINA) была заменена моделью поставщика учетных данных, что позволило перечислять различные типы входа в систему с помощью плиток входа в систему. Обе модели описаны ниже.

Архитектура графической идентификации и аутентификации

Архитектура графической идентификации и аутентификации (GINA) применима к операционным системам Windows Server 2003, Microsoft Windows 2000 Server, Windows XP и Windows 2000 Professional.В этих системах каждый сеанс интерактивного входа в систему создает отдельный экземпляр службы Winlogon. Архитектура GINA загружается в пространство процессов, используемое Winlogon, принимает и обрабатывает учетные данные и выполняет вызовы интерфейсов аутентификации через LSALogonUser.

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

На следующей схеме показан процесс учетных данных для Windows Server 2003, Microsoft Windows 2000 Server, Windows XP и Microsoft Windows 2000 Professional.

Архитектура поставщика учетных данных

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

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

Поставщики учетных данных не являются механизмами принудительного применения. Они используются для сбора и сериализации учетных данных. Пакеты Local Security Authority и аутентификации обеспечивают безопасность.

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

• Описание учетных данных, необходимых для аутентификации.

• Обработка связи и логики с внешними центрами аутентификации.

• Упаковка учетных данных для интерактивного входа и входа в сеть.

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

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

Каждая версия Windows содержит одного поставщика учетных данных по умолчанию и одного поставщика предварительного доступа (PLAP) по умолчанию, также известного как поставщик SSO. Поставщик единого входа позволяет пользователям подключаться к сети перед входом в систему на локальном компьютере. Когда этот поставщик реализован, он не перечисляет плитки в пользовательском интерфейсе входа в систему.

Поставщик SSO предназначен для использования в следующих сценариях:

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

  • У пользователя есть возможность подключиться к сети, например, подключиться к виртуальной частной сети (VPN), прежде чем войти в систему, но не требуется для этого подключения.

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

  • За несколькими сетевыми аутентификациями следует один из других сценариев. Например, пользователь проходит аутентификацию у поставщика услуг Интернета (ISP), аутентифицируется в сети VPN, а затем использует учетные данные своей учетной записи для локального входа в систему.

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

  • У пользователя домена не настроена локальная учетная запись на компьютере, присоединенном к домену, и он должен установить подключение к службам удаленного доступа через VPN-соединение до завершения интерактивного входа в систему.

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

Список плиток входа в систему

Поставщик учетных данных перечисляет плитки входа в систему в следующих случаях:

• Для операционных систем, указанных в . Применяется к списку в начале этого раздела.

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

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

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

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

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

Ввод учетных данных для входа в приложение и службу

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

Системные службы и приложения транспортного уровня получают доступ к поставщику поддержки безопасности (SSP) через интерфейс поставщика поддержки безопасности (SSPI) в Windows, который предоставляет функции для перечисления пакетов безопасности, доступных в системе, выбора пакета и использования этого пакета для получить аутентифицированное соединение.

Когда соединение клиент / сервер аутентифицировано:

• Приложение на стороне клиента соединения отправляет учетные данные на сервер с помощью функции SSPI InitializeSecurityContext (General) .

• Приложение на стороне сервера соединения отвечает функцией SSPI AcceptSecurityContext (General) .

• Функции SSPI InitializeSecurityContext (General), и AcceptSecurityContext (General) повторяются до тех пор, пока все необходимые сообщения аутентификации не будут обменены для успешной или неудачной аутентификации.

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

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

Приложения и пользовательский режим

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

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

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

SSPI доступен через модуль Secur32.dll, который представляет собой API, используемый для получения интегрированных служб безопасности для аутентификации, целостности сообщений и конфиденциальности сообщений. Он обеспечивает уровень абстракции между протоколами уровня приложений и протоколами безопасности. Поскольку для разных приложений требуются разные способы идентификации или аутентификации пользователей и разные способы шифрования данных при их перемещении по сети, SSPI предоставляет способ доступа к библиотекам динамической компоновки (DLL), которые содержат различные функции аутентификации и криптографии.Эти библиотеки DLL называются поставщиками поддержки безопасности (SSP).

Управляемые учетные записи служб и виртуальные учетные записи были введены в Windows Server 2008 R2 и Windows 7 для обеспечения важных приложений, таких как Microsoft SQL Server и Internet Information Services (IIS), с изоляцией их собственных учетных записей домена, устраняя при этом необходимость в администратор, чтобы вручную администрировать имя участника-службы (SPN) и учетные данные для этих учетных записей. Для получения дополнительных сведений об этих функциях и их роли в проверке подлинности см. Документацию по управляемым учетным записям служб для Windows 7 и Windows Server 2008 R2 и Обзор групповых управляемых учетных записей служб.

Службы и режим ядра

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

Примечание

Службы обычно запускаются в контекстах безопасности, известных как локальная система (СИСТЕМА), сетевая служба или локальная служба.В Windows Server 2008 R2 представлены службы, которые запускаются под управляемой учетной записью службы, которая является участниками домена.

Перед запуском службы контроллер службы входит в систему, используя учетную запись, назначенную для службы, а затем представляет учетные данные службы для аутентификации LSA. Служба Windows реализует программный интерфейс, который диспетчер контроллера службы может использовать для управления службой. Служба Windows может запускаться автоматически при запуске системы или вручную с помощью программы управления службами.Например, когда клиентский компьютер Windows присоединяется к домену, служба обмена сообщениями на компьютере подключается к контроллеру домена и открывает для него защищенный канал. Чтобы получить соединение с проверкой подлинности, служба должна иметь учетные данные, которым доверяет локальный центр безопасности (LSA) удаленного компьютера. При взаимодействии с другими компьютерами в сети LSA использует учетные данные для учетной записи домена локального компьютера, как и все другие службы, работающие в контексте безопасности локальной системы и сетевой службы.Службы на локальном компьютере работают как СИСТЕМА, поэтому учетные данные не нужно предоставлять LSA.

Файл Ksecdd.sys управляет этими учетными данными, шифрует их и использует локальный вызов процедуры в LSA. Тип файла — DRV (драйвер), известный как поставщик поддержки безопасности режима ядра (SSP), и в тех версиях, которые указаны в списке Применимо к в начале этого раздела, это FIPS 140-2 уровня 1- совместимый.

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

Местный орган безопасности

Local Security Authority (LSA) — это защищенный системный процесс, который аутентифицирует и регистрирует пользователей на локальном компьютере. Кроме того, LSA хранит информацию обо всех аспектах локальной безопасности на компьютере (эти аспекты в совокупности известны как локальная политика безопасности) и предоставляет различные службы для преобразования между именами и идентификаторами безопасности (SID).Процесс системы безопасности, Local Security Authority Server Service (LSASS), отслеживает политики безопасности и учетные записи, которые действуют в компьютерной системе.

LSA проверяет личность пользователя на основе того, какой из следующих двух объектов предоставил учетную запись пользователя:

• Местный орган безопасности. LSA может проверить информацию о пользователе, проверив базу данных диспетчера учетных записей безопасности (SAM), расположенную на том же компьютере. Любая рабочая станция или рядовой сервер может хранить локальные учетные записи пользователей и информацию о локальных группах.Однако эти учетные записи можно использовать для доступа только к этой рабочей станции или компьютеру.

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

Служба подсистемы Local Security Authority (LSASS) хранит учетные данные в памяти от имени пользователей с активными сеансами Windows.Сохраненные учетные данные позволяют пользователям беспрепятственно получать доступ к сетевым ресурсам, таким как общие файловые ресурсы, почтовые ящики Exchange Server и сайты SharePoint, без повторного ввода учетных данных для каждой удаленной службы.

LSASS может хранить учетные данные в нескольких формах, в том числе:

• Открытый текст с обратимым шифрованием

• Билеты Kerberos (билеты выдачи билетов (TGT), служебные билеты)

• NT хеш

• Хэш LAN Manager (LM)

Если пользователь входит в Windows с помощью смарт-карты, LSASS не сохраняет пароль в виде открытого текста, но сохраняет соответствующее хеш-значение NT для учетной записи и ПИН-код в виде открытого текста для смарт-карты.Если атрибут учетной записи включен для смарт-карты, которая требуется для интерактивного входа в систему, для учетной записи автоматически создается случайное значение хэша NT вместо исходного хэша пароля. Хэш пароля, который автоматически создается при установке атрибута, не изменяется.

Если пользователь входит в систему на компьютере под управлением Windows с паролем, совместимым с хэшами LAN Manager (LM), этот аутентификатор присутствует в памяти.

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

Сохраненные учетные данные напрямую связаны с сеансами входа в систему службы подсистемы локального администратора безопасности (LSASS), которые были запущены после последнего перезапуска и не были закрыты. Например, сеансы LSA с сохраненными учетными данными LSA создаются, когда пользователь выполняет любое из следующих действий:

• Вход в локальный сеанс или сеанс протокола удаленного рабочего стола (RDP) на компьютере

• Запускает задачу с использованием параметра RunAs option

• Запускает активную службу Windows на компьютере

• Запускает запланированную задачу или пакетное задание

• Запускает задачу на локальном компьютере с помощью инструмента удаленного администрирования

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

• Пароль учетной записи для учетной записи доменных служб Active Directory (AD DS) компьютера

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

• Пароли учетных записей для настроенных запланированных задач

• Пароли учетных записей для пулов приложений IIS и веб-сайтов

• Пароли для учетных записей Microsoft

Введено в Windows 8.1, клиентская операционная система обеспечивает дополнительную защиту LSA для предотвращения чтения памяти и внедрения кода незащищенными процессами. Эта защита повышает безопасность учетных данных, которые LSA хранит и управляет.

Дополнительные сведения об этих дополнительных средствах защиты см. В разделе Настройка дополнительной защиты LSA.

Кэшированные учетные данные и проверка

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

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

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

Хранение и проверка учетных данных

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

Процессы учетных данных для удаленного входа

Протокол удаленного рабочего стола (RDP) управляет учетными данными пользователя, который подключается к удаленному компьютеру с помощью клиента удаленного рабочего стола, который был представлен в Windows 8.Учетные данные в текстовой форме отправляются на целевой хост, где хост пытается выполнить процесс аутентификации и, в случае успеха, подключает пользователя к разрешенным ресурсам. RDP не хранит учетные данные на клиенте, но учетные данные домена пользователя хранятся в LSASS.

Представленный в Windows Server 2012 R2 и Windows 8.1, режим ограниченного администратора обеспечивает дополнительную безопасность для сценариев удаленного входа в систему. В этом режиме удаленного рабочего стола клиентское приложение выполняет запрос-ответ на вход в сеть с односторонней функцией NT (NTOWF) или использует билет службы Kerberos при аутентификации на удаленном узле.После аутентификации администратора у него нет соответствующих учетных данных в LSASS, поскольку они не были предоставлены удаленному узлу. Вместо этого у администратора есть учетные данные учетной записи компьютера для сеанса. Учетные данные администратора не предоставляются удаленному узлу, поэтому действия выполняются от имени учетной записи компьютера. Ресурсы также ограничены учетной записью компьютера, и администратор не может получить доступ к ресурсам со своей учетной записью.

Автоматический перезапуск процесса учетных данных для входа

Когда пользователь входит в систему Windows 8.1, LSA сохраняет учетные данные пользователя в зашифрованной памяти, доступной только для LSASS.exe. Когда Центр обновления Windows инициирует автоматический перезапуск без присутствия пользователя, эти учетные данные используются для настройки Autologon для пользователя.

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

Дополнительные сведения об ARSO см. В разделе «Автоматический перезапуск Winlogon» (ARSO).

Сохраненные имена пользователей и пароли в Windows Vista и Windows XP

В Windows Server 2008, Windows Server 2003, Windows Vista и Windows XP сохраненные имена пользователей и пароли на панели управления упрощает управление и использование нескольких наборов учетных данных, включая сертификаты X.509, используемые со смарт-картами и Windows Живые учетные данные (теперь называемые учетной записью Microsoft).Учетные данные — часть профиля пользователя — хранятся до тех пор, пока они не понадобятся. Это действие может повысить безопасность для каждого ресурса, гарантируя, что если один пароль будет скомпрометирован, он не поставит под угрозу всю безопасность.

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

Действуют следующие ограничения:

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

• Сохраненные имена пользователей и пароли хранит учетные данные только для NTLM, протокола Kerberos, учетной записи Microsoft (ранее Windows Live ID) и аутентификации Secure Sockets Layer (SSL).Некоторые версии Internet Explorer поддерживают собственный кеш для базовой проверки подлинности.

Эти учетные данные становятся зашифрованной частью локального профиля пользователя в каталоге \ Documents and Settings \ Username \ Application Data \ Microsoft \ Credentials. В результате эти учетные данные могут перемещаться вместе с пользователем, если сетевая политика пользователя поддерживает перемещаемые профили пользователей. Однако, если у пользователя есть копии сохраненных имен пользователей и паролей на двух разных компьютерах и он изменяет учетные данные, связанные с ресурсом на одном из этих компьютеров, изменение не распространяется на сохраненных имен пользователей и паролей на второй компьютер.

Хранилище Windows и диспетчер учетных данных

Диспетчер учетных данных

был представлен в Windows Server 2008 R2 и Windows 7 как функция панели управления для хранения и управления именами пользователей и паролями. Credential Manager позволяет пользователям хранить учетные данные, относящиеся к другим системам и веб-сайтам, в безопасном хранилище Windows. Некоторые версии Internet Explorer используют эту функцию для аутентификации на веб-сайтах.

Управление учетными данными с помощью Credential Manager контролируется пользователем на локальном компьютере.Пользователи могут сохранять и хранить учетные данные из поддерживаемых браузеров и приложений Windows, чтобы им было удобно выполнять вход на эти ресурсы. Учетные данные сохраняются в специальных зашифрованных папках на компьютере под профилем пользователя. Приложения, поддерживающие эту функцию (с помощью API-интерфейсов Credential Manager), например веб-браузеры и приложения, могут предоставлять правильные учетные данные другим компьютерам и веб-сайтам во время процесса входа в систему.

Когда веб-сайт, приложение или другой компьютер запрашивает аутентификацию через NTLM или протокол Kerberos, появляется диалоговое окно, в котором вы устанавливаете флажок Обновить учетные данные по умолчанию или Сохранить пароль .Это диалоговое окно, позволяющее пользователю сохранять учетные данные локально, создается приложением, которое поддерживает API-интерфейсы Credential Manager. Если пользователь устанавливает флажок Сохранить пароль , Credential Manager отслеживает имя пользователя, пароль и соответствующую информацию для используемой службы аутентификации.

При следующем использовании службы Credential Manager автоматически предоставит учетные данные, которые хранятся в Windows Vault. Если он не принят, пользователю предлагается ввести правильную информацию для доступа.Если доступ предоставляется с новыми учетными данными, Credential Manager заменяет предыдущие учетные данные новыми, а затем сохраняет новые учетные данные в хранилище Windows Vault.

База данных диспетчера учетных записей безопасности

Менеджер учетных записей безопасности (SAM) — это база данных, в которой хранятся локальные учетные записи и группы пользователей. Он присутствует в каждой операционной системе Windows; однако, когда компьютер присоединяется к домену, Active Directory управляет учетными записями домена в доменах Active Directory.

Например, клиентские компьютеры под управлением операционной системы Windows участвуют в сетевом домене, взаимодействуя с контроллером домена, даже если в систему не вошел пользователь-человек.Чтобы инициировать обмен данными, компьютер должен иметь активную учетную запись в домене. Перед принятием связи с компьютера LSA на контроллере домена проверяет подлинность компьютера, а затем создает контекст безопасности компьютера так же, как это делается для участника безопасности человека. Этот контекст безопасности определяет личность и возможности пользователя или службы на конкретном компьютере или пользователя, службы или компьютера в сети. Например, маркер доступа, содержащийся в контексте безопасности, определяет ресурсы (например, общий файловый ресурс или принтер), к которым можно получить доступ, и действия (такие как чтение, запись или изменение), которые могут быть выполнены этим принципалом — пользователем. , компьютер или сервис на этом ресурсе.

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

Локальные домены и доверенные домены

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

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

Для получения информации о доверительных отношениях домена и леса при проверке подлинности см. Делегированная проверка подлинности и доверительные отношения.

Сертификаты при проверке подлинности Windows

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

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

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

Удаленные узлы устанавливают свою надежность, получая сертификат от центра сертификации (ЦС). Центр сертификации, в свою очередь, может иметь сертификат вышестоящего органа, что создает цепочку доверия. Чтобы определить, заслуживает ли сертификат доверия, приложение должно определить идентификатор корневого ЦС, а затем определить, заслуживает ли он доверия.

Точно так же удаленный хост или локальный компьютер должен определить, является ли сертификат, представленный пользователем или приложением, подлинным.Сертификат, представленный пользователем через LSA и SSPI, оценивается на аутентичность на локальном компьютере для локального входа в систему, в сети или в домене через хранилища сертификатов в Active Directory.

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

Примечание

SHA1 используется по умолчанию в Windows 7 и Windows Vista, но был изменен на SHA2 в Windows 8.

Аутентификация смарт-карты

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

Для получения информации об аутентификации смарт-карты см. Технический справочник по смарт-карте Windows.

Технология виртуальной смарт-карты

была представлена ​​в Windows 8. Она хранит сертификат смарт-карты на ПК, а затем защищает его с помощью микросхемы безопасности доверенного платформенного модуля (TPM) с защитой от несанкционированного доступа. Таким образом, ПК фактически становится смарт-картой, которая должна получить PIN-код пользователя для аутентификации.

Удаленная и беспроводная аутентификация

Удаленная и беспроводная сетевая аутентификация — еще одна технология, использующая сертификаты для аутентификации.Служба проверки подлинности в Интернете (IAS) и серверы виртуальных частных сетей используют протокол расширенной проверки подлинности на транспортном уровне (EAP-TLS), защищенный протокол расширенной проверки подлинности (PEAP) или безопасность протокола Интернета (IPsec) для выполнения проверки подлинности на основе сертификатов для многих типов. сетевого доступа, включая виртуальную частную сеть (VPN) и беспроводные соединения.

Для получения информации об аутентификации на основе сертификатов в сети см. Аутентификация доступа к сети и сертификаты.

См. Также

Концепции проверки подлинности Windows

Руководство по настройке аутентификации, авторизации и учета

, Cisco IOS версии 15M & T — Настройка аутентификации [Поддержка]

Предположим, системный администратор выбрал решение безопасности, в котором все интерфейсы будут использовать одни и те же методы аутентификации для аутентификации PPP-соединений. В группе RADIUS сначала связывается с R1 для получения информации об аутентификации; если нет ответа, связывается с R2.Если R2 не отвечает, устанавливается связь с T1 в группе TACACS +; если T1 не отвечает, связывается с T2. Если все назначенные серверы не отвечают, проверка подлинности выполняется в локальной базе данных имен пользователей на сервере доступа. Для реализации этого решения системный администратор может создать список методов по умолчанию, введя следующую команду:

aaa аутентификация ppp группа по умолчанию радиус группа tacacs + local
 

В приведенном выше примере «default» — это имя списка методов.Протоколы, включенные в этот список методов, перечислены после имени в том порядке, в котором они запрашиваются. Список по умолчанию автоматически применяется ко всем интерфейсам.

Когда удаленный пользователь пытается подключиться к сети, сервер доступа к сети сначала запрашивает у R1 информацию для аутентификации. Если R1 аутентифицирует пользователя, он выдает ответ PASS серверу доступа к сети, и пользователю разрешается доступ к сети. Если R1 возвращает FAIL-ответ, пользователю отказывают в доступе и сеанс завершается.Если R1 не отвечает, то сервер доступа к сети обрабатывает это как ОШИБКУ и запрашивает у R2 информацию для аутентификации. Этот шаблон продолжается через оставшиеся назначенные методы до тех пор, пока пользователь не будет аутентифицирован или отклонен, или пока сеанс не будет завершен.

Обратите внимание, что ответ FAIL значительно отличается от ERROR. ОТКАЗ означает, что пользователь не соответствует критериям, содержащимся в соответствующей базе данных аутентификации для успешной аутентификации.Аутентификация завершается ответом FAIL. ОШИБКА означает, что сервер безопасности не ответил на запрос аутентификации. Из-за этого попытки аутентификации не выполнялись. Только при обнаружении ОШИБКИ AAA выберет следующий метод аутентификации, определенный в списке методов аутентификации.

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

aaa аутентификация ppp группа по умолчанию радиус группа tacacs + local
aaa аутентификация ppp apple group radius group tacacs + local none
 интерфейс async 3
 ppp аутентификация глава list1
 

В приведенном выше примере «list1» — это имя списка методов, а протоколы, включенные в этот список методов, перечислены после имени в том порядке, в котором они должны выполняться.После того, как список методов создан, он применяется к соответствующему интерфейсу. Обратите внимание, что имя списка методов (list1) как в аутентификация aaa и Команды аутентификации ppp должны совпадать.

В следующем примере системный администратор использует группы серверов, чтобы указать, что только R2 и T2 являются допустимыми серверами для аутентификации PPP. Для этого администратор должен определить определенные группы серверов с R2 (192.0.2.3) и T2 (192.0.2.17) в качестве членов. В приведенном ниже примере группа серверов RADIUS «rad2only» определяется следующим образом с использованием ааа группа команда сервера:

Радиус сервера группы aaa rad2only
 сервер 192.0.2.3
 

Группа серверов TACACS + «tac2only» определяется следующим образом с помощью ааа группа команда сервера:

aaa group server tacacs + tac2only
 сервер 192.0.2.17
 

Затем администратор применяет аутентификацию PPP, используя группы серверов. В приведенном ниже примере список методов по умолчанию для аутентификации PPP следует в следующем порядке: группа rad2only, группа tac2only и местный:

aaa аутентификация ppp группа по умолчанию rad2only group tac2only local 

NVD — Контроль — IA-1

Специальная публикация NIST 800-53 (Rev.4)

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

IA-1 ПОЛИТИКА И ПРОЦЕДУРЫ ИДЕНТИФИКАЦИИ И Аутентификации

Описание элемента управления

Организация:

а.Разрабатывает, документирует и распространяет среди [Назначение: персонал или роли, определенные организацией]:

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

2.Процедуры, способствующие реализации политики идентификации и аутентификации и связанных с ней средств управления идентификацией и аутентификацией; и

б. Проверяет и обновляет текущие:

1. Политика идентификации и аутентификации [Назначение: частота, определяемая организацией]; и

2.Процедуры идентификации и аутентификации [Назначение: частота, определяемая организацией].

Дополнительное руководство

Этот элемент управления направлен на создание политики и процедур для эффективной реализации выбранных мер безопасности и улучшений управления в семействе IA.