Аутентификация по ключам доступа
Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.
В большинстве случаев, сервер генерирует ключи доступа по запросу пользователей, которые далее сохраняют эти ключи в клиентских приложениях. При создании ключа также возможно ограничить срок действия и уровень доступа, который получит клиентское приложение при аутентификации с помощью этого ключа.
Kestrel
Пакет NuGet Microsoft.AspNetCore.Authentication.Negotiate можно использовать для Kestrel поддержки проверки подлинности Windows с помощью Negotiate и Kerberos в Windows, Linux и macOS.
Предупреждение
Учетные данные можно сохранять в запросах к подключению. Проверка подлинности согласований не должна использоваться с прокси-серверами, если прокси-сервер не поддерживает сходство подключений 1:1 (постоянное соединение) с Kestrel.
Примечание
Обработчик negotiate определяет, поддерживает ли базовый сервер проверку подлинности Windows в собственном коде и включена ли она. Если сервер поддерживает проверку подлинности Windows, но он отключен, возникает ошибка с запросом на включение реализации сервера. Если проверка подлинности Windows включена на сервере, обработчик negotiate прозрачно перенаправит запросы на проверку подлинности.
Добавление служб проверки подлинности путем вызова AddAuthentication и AddNegotiate в :
Добавление ПО промежуточного слоя проверки подлинности путем вызоваUseAuthentication:
Дополнительные сведения о ПО промежуточного слоя см. в разделе ASP.NET Core ПО промежуточного слоя.
Проверка подлинности Kerberos и управление доступом на основе ролей (RBAC)
Проверка подлинности Kerberos в Linux или macOS не предоставляет сведения о роли для пользователя, прошедшего проверку подлинности. Чтобы добавить сведения о роли и группе пользователю Kerberos, обработчик проверки подлинности должен быть настроен для получения ролей из домена LDAP. Основная конфигурация указывает только домен LDAP для запроса и будет использовать контекст пользователя, прошедшего проверку подлинности, для запроса домена LDAP:
Для некоторых конфигураций могут потребоваться определенные учетные данные для запроса домена LDAP. Учетные данные можно указать в следующих выделенных параметрах:
По умолчанию обработчик проверки подлинности negotiate разрешает вложенные домены. В крупной или сложной среде LDAP разрешение вложенных доменов может привести к медленному поиску или использованию большого объема памяти для каждого пользователя. Разрешение вложенных доменов можно отключить с помощью параметра .
Анонимные запросы разрешены. Используйте ASP.NET Core авторизации для запроса анонимных запросов на проверку подлинности.
AuthenticationScheme требуется пакет NuGet Microsoft.AspNetCore.Authentication.Negotiate.
Конфигурация среды Windows
Компонент Microsoft.AspNetCore.Authentication.Negotiate выполняет проверку подлинности в пользовательском режиме . Имена субъектов-служб (SPN) необходимо добавить в учетную запись пользователя, на котором запущена служба, а не учетная запись компьютера. Выполните в командной оболочке администратора.
Конфигурация среды Linux и macOS
Инструкции по присоединению компьютера Linux или macOS к домену Windows доступны в статье «. Инструкции по созданию учетной записи компьютера Linux в домене. Имена субъектов-служб необходимо добавить в учетную запись компьютера.
Примечание
При выполнении инструкций, приведенных в статье , замените его при необходимости.
После присоединения компьютера Linux или macOS к домену необходимо выполнить дополнительные действия, чтобы предоставить файл keytab с именами субъектов-служб:
- На контроллере домена добавьте новые имена субъектов-служб веб-службы в учетную запись компьютера:
- Создайте файл keytab с помощью ktpass :
- Некоторые поля должны быть указаны в верхнем регистре, как указано.
- Скопируйте файл keytab на компьютер Linux или macOS.
- Выберите файл keytab с помощью переменной среды:
- Вызов для отображения имен субъектов-служб, доступных в настоящее время для использования.
Примечание
Файл keytab содержит учетные данные для доступа к домену и должен быть защищен соответствующим образом.
Аутентификация по паролю
Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.
Применительно к веб-приложениям, существует несколько стандартных протоколов для аутентификации по паролю, которые мы рассмотрим ниже.
HTTP authentication
Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и работает следующим образом:
Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус «401 Unauthorized» и добавляет заголовок «WWW-Authenticate» с указанием схемы и параметров аутентификации.
Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок «Authorization», в котором передаются данные пользователя для аутентификации сервером.
Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.
Весь процесс стандартизирован и хорошо поддерживается всеми браузерами и веб-серверами. Существует несколько схем аутентификации, отличающихся по уровню безопасности:
Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.
Пример работы на PHP рассмотрен в статье HTTP-аутентификация
Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.
Стоит отметить, что при использовании HTTP-аутентификации у пользователя нет стандартной возможности выйти из веб-приложения, кроме как закрыть все окна браузера.
Forms authentication
Для этого протокола нет определенного стандарта, поэтому все его реализации специфичны для конкретных систем, а точнее, для модулей аутентификации фреймворков разработки.
Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.
Приложение может создать session token двумя способами:
Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».
Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.
Этапы входа пользователя в систему
Login в Windows начинается, когда пользователь нажимает SAS комбинацию (Ctrl+Alt+Delete). Далее Winlogon запускает LogonUI, который вызывает поставщика учетных данных. Winlogon также создает для этого пользователя уникальный SID входа в систему, этот SID попадает в маркер доступа.
После ввода имени пользователя и пароля Winlogon обращается к LSASS. Как только LSASS проверит пользователя, Winlogon продолжит процесс входа. Если LSASS в ходе проверки не узнает пользователя, то процесс входа для него прекращается.
Для интерактивного входа используются два стандартных пакета аутентификации:
- MSV1_0 — на автономном компьютере. Он принимает логин и хеш введенного пароля и отправляет запрос локальному SAM-администратору для извлечения информации об учетной записи. Извлекается имя учетной записи, его группы и хеш пароля. На основе этой информации принимается решение, пускать пользователя в систему или нет.
- Kerberos — на компьютере в домене. Процесс входа похож на первый, но в этом случае компьютеру в домене нужно еще обмениваться информацией с контроллером домена. Такой обмен выполняется по протоколу Kerberos, который обеспечивает безопасную среду передачи информации от рабочей станции к контроллеру домена в ходе аутентификации.
Затем Winlogon ищет в реестре значение параметра HKLM\SOFTWARE \ Microsoft\Windows NT\Current Version\Winlogon\Userinit и на его основе создает первый процесс пользователя. По умолчанию это Userinit, который загружает профиль пользователя, а затем загружает оболочку пользователя из параметра HKCU\SOFTWARE\ Microsoft\Windows NT\Current Version\Winlogon\Shell или из HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Shell. По умолчанию оболочка пользователя — Explorer.exe. Затем происходит выход из Userinit. Именно поэтому для Explorer.exe не показывается родительский процесс при просмотре в Process Explorer.
Авторизация пользователей
Состояние конфигурации анонимного доступа определяет способ использования и атрибутов в приложении. В следующих двух разделах объясняется, как обрабатывать запрещенные и разрешенные состояния конфигурации анонимного доступа.
Запрет анонимного доступа
Если проверка подлинности Windows включена и анонимный доступ отключен, атрибуты не влияют. Если сайт IIS настроен для запрета анонимного доступа, запрос никогда не достигает приложения. По этой причине атрибут неприменим.
Разрешить анонимный доступ
Если включена проверка подлинности Windows и анонимный доступ, используйте и атрибуты. Атрибут позволяет защитить конечные точки приложения, для которых требуется проверка подлинности. Атрибут переопределяет атрибут в приложениях, которые разрешают анонимный доступ. Сведения об использовании атрибутов см. в разделе «Простая авторизация» в ASP.NET Core.
Примечание
По умолчанию пользователи, не имеющие разрешения на доступ к странице, получают пустой ответ HTTP 403. можно настроить для предоставления пользователям более эффективного интерфейса «Отказано в доступе».
Проверка подлинности и авторизация: аналогия перемещения
Аналогия путешествия может помочь объяснить, как работает проверка подлинности. Для начала процесса обычно необходимо выполнить несколько подготовительных задач. Путешественник должен доказать свою истинную личность для своих ведущих властей. Это доказательство может быть в виде подтверждения гражданства, места рождения, личного ваучера, фотографий или любого, что требуется законом принимающей страны. Удостоверение путешественника проверяется путем выдачи паспорта, который аналогичен системной учетной записи, выданной и администрируемой организацией- субъектом безопасности. Паспорт и предполагаемое назначение основаны на наборе правил и правил, выданных государственным органом.
Путешествие
Когда путешественник прибывает на международную границу, пограничный охранник просит учетные данные, и путешественник представляет свой паспорт. Процесс состоит из двух вариантов:
-
Охранник проверяет подлинность паспорта, убедившись, что он был выдан органом безопасности, что местное правительство доверяет (доверяет, по крайней мере, выдавать паспорта) и проверяя, что паспорт не был изменен.
-
Охранник проверяет подлинность путешественника, убедившись, что лицо соответствует лицу человека, изображенного на паспорте, и что другие необходимые учетные данные находятся в хорошем порядке.
Если паспорт окажется действительным, и путешественник докажется быть его владельцем, проверка подлинности успешна, и путешественник может быть разрешен доступ через границу.
Транзитивное доверие между органами безопасности является основой проверки подлинности; Тип проверки подлинности, происходящий на международной границе, основан на доверии. Местное правительство не знает путешественника, но он доверяет, что принимающее правительство делает. Когда принимающее правительство выпустило паспорт, он не знал путешественника либо. Оно доверяет агентству, которое выдало свидетельство о рождении или другую документацию. Агентство, выдавающее свидетельство о рождении, в свою очередь, доверяет врачу, подписавшему сертификат. Врач следил за рождением путешественника и штампировал сертификат с прямым доказательством личности, в данном случае с следом новорожденного. Доверие, которое передается таким образом через доверенных посредников, является транзитивным.
Транзитивное доверие является основой сетевой безопасности в архитектуре клиента или сервера Windows. Отношения доверия передаются по всему набору доменов, например в дереве доменов, и формирует связь между доменом и всеми доменами, которые доверяют данному домену. Например, если домен A имеет транзитивное доверие с доменом B, а если домен B доверяет доменУ C, домен A доверяет доменУ C.
Существует разница между проверкой подлинности и авторизацией. При проверке подлинности система доказывает, что вы являетесь тем, кто вы говорите, что вы. При авторизации система проверяет, есть ли у вас права на то, что вы хотите сделать. Чтобы принять аналогию границы к следующему шагу, просто аутентификсируя, что путешественник является правильным владельцем действительного паспорта не обязательно авторизует путешественника въехать в страну. Жители конкретной страны могут въезжать в другую страну, просто предоставляя паспорт только в тех ситуациях, когда страна, введенная в страну, предоставляет неограниченное разрешение для всех граждан этой конкретной страны для входа.
Аналогичным образом можно предоставить всем пользователям разрешения на доступ к ресурсу из определенного домена. Любой пользователь, принадлежащий этому домену, имеет доступ к ресурсу, так же, как Канада позволяет гражданам США въехать в Канаду. Однако граждане США, пытающиеся въехать в Бразилию или Индию, считают, что они не могут въехать в эти страны, просто представляя паспорт, потому что обе эти страны требуют посещения граждан США, чтобы иметь действительную визу. Таким образом, проверка подлинности не гарантирует доступ к ресурсам или авторизации для использования ресурсов.
Требования нормативных документов к механизму идентификации и аутентификации
Прежде всего, напомним основные понятия. Идентификация —
это процесс распознавания элемента системы, обычно с помощью заранее
определенного идентификатора или другой уникальной информации — каждый субъект
или объект системы должен быть однозначно идентифицируем. Аутентификация — это
проверка подлинности идентификации пользователя, процесса, устройства или
другого компонента системы (обычно осуществляется перед разрешением доступа).
Прежде всего, обратимся к формализованным требованиям в
области защиты информации, попробуем в них найти ответ на вопрос, какими же
функциями должен быть наделен механизм идентификации и аутентификации?
Формализованные требования к механизму идентификации и аутентификации
пользователей задаются действующим сегодня нормативным документом
«Гостехкомиссия России. Руководящий документ. Средства вычислительной
техники. Защита от несанкционированного доступа к информации. Показатели
защищенности от НСД к информации».
Для СЗИ от НСД, используемых для защиты конфиденциальной
информации (5 класс СВТ) требования к механизму идентификации и аутентификации
состоят в следующем:
● Комплекс
средств защиты информации (КСЗ) должен требовать от пользователей
идентифицировать себя при запросах на доступ.
● КСЗ
должен подвергать проверке подлинность идентификации — осуществлять
аутентификацию.
● КСЗ
должен располагать необходимыми данными для идентификации и аутентификации.
● КСЗ
должен препятствовать доступу к защищаемым ресурсам неидентифицированных
пользователей и пользователей, подлинность идентификации которых при
аутентификации не подтвердилась.
Видим, что, выдвигается требование, состоящее в
необходимости идентификации и аутентификации пользователя именно при запросах
на доступ.
Заметим, что в требованиях к СВТ 4-го класса защищенности
вообще задачи идентификации и аутентификации пользователя при входе в систему и
при запросе на доступ разделены на две самостоятельные задачи, кроме того,
здесь появляется некое понятие «субъект» в общем виде.
Что же представляет собою запрос на доступ к ресурсу? В
общем случае подобный запрос может быть охарактеризован тем, какой пользователь
обращается к ресурсу (идентификатор пользователя, определяющий, кому нужен
ресурс), какой процесс (приложение) обращается к ресурсу (идентификатор
процесса, определяющий для решения каких задач пользователю нужен ресурс), и,
собственно, к какому ресурсу осуществляется обращение (идентификатор объекта
доступа).
Естественно, возникает вопрос, с какой целью необходима
какая-либо идентификация и аутентификация субъекта и объекта доступа при
запросах на доступ к ресурсу. Ведь в любой системе защиты предполагается, что
реализуется механизм идентификации и аутентификации пользователя при входе в
систему. Результатом этого является однозначная идентификация пользователя,
запускаемые им процессы наследуют этот идентификатор, т.е. именно от лица
идентифицированного пользователя и обращаются к ресурсу, на чем, кстати говоря,
и строится в своей основе разграничительная политика доступа к ресурсам. С
объектом доступа вообще все понятно, например, файловый объект, казалось бы,
однозначно идентифицируется своим полнопутевым именем. Какие здесь еще
проблемы?
Настройка выбора нового сертификата — элементы конфигурации
Используйте Выбор нового сертификата для настройки критериев, которые клиентские компьютеры будут использовать для автоматического выбора правильного сертификата из числа имеющихся в целях проверки подлинности. При предоставлении конфигурации клиентским компьютерам сети через политики проводной сети (IEEE 802.3), политики беспроводной сети (IEEE 802.11) или пакет администрирования диспетчера подключений для VPN клиенты автоматически снабжаются указанными критериями проверки подлинности.
В этом разделе перечислены элементы конфигурации для выбора нового сертификата, а также описание каждого из них.
Этот элемент указывает, включена ли фильтрация издателей сертификатов.
По умолчанию — не выбран.
Используется для указания одного или нескольких издателей для сертификатов.
Перечисляет имена всех издателей, сертификаты соответствующих центров сертификации (ЦС) для которых содержатся в хранилищах сертификатов Доверенные корневые центры сертификации или Промежуточные центры сертификации учетной записи локального компьютера.
-
Включает все корневые центры сертификации и промежуточные центры сертификации.
-
Содержит только тех издателей, допустимые (например, не истекшие и не отозванные) сертификаты которых имеются на компьютере.
Итоговый список сертификатов, которые можно использовать для проверки подлинности, содержит только сертификаты, выпущенные издателями, которые выбраны в этом списке.
По умолчанию — не выбрано ничего.
Расширенное использование ключа (EKU)
Можно выбрать все назначение, проверку подлинности клиента, любую цельили любое сочетание этих параметров. Указывает, что при выборе любого сочетания трех условий выше все сертификаты, соответствующие выбранным условиям, считаются допустимыми сертификатами для проверки подлинности клиента на сервере. Если фильтрация EKU включена, необходимо выбрать одно из трех условий; в ином случае команда ОК будет отключена.
По умолчанию — не включено.
Все
Если этот флажок установлен, то сертификаты, имеющие EKU для всех целей , считаются действительными сертификатами в целях проверки подлинности клиента на сервере.
Значение по умолчанию — выбрано, если выбрано Расширенное использование ключа (EKU)
Аутентификация клиента
Если этот флажок установлен, этот элемент указывает, что сертификаты с EKU проверки подлинности клиента и указанный список EKU считаются действительными сертификатами для проверки подлинности клиента на сервере.
Значение по умолчанию — выбрано, если выбрано Расширенное использование ключа (EKU)
Любая цель
Если этот флажок установлен, этот элемент указывает, что для проверки подлинности клиента на сервере все сертификаты с любыми EKU и указанным списком EKU считаются действительными сертификатами.
Значение по умолчанию — выбрано, если выбрано Расширенное использование ключа (EKU)
Добавить
Этот элемент открывает диалоговое окно Выбор EKU , которое позволяет добавлять стандартные, настраиваемые или зависящие от поставщика EKU для проверки подлинности клиента или любого из списков целей.
По умолчанию — в списке нет EKU.
Удалить
Этот элемент удаляет выбранное EKU из списка проверки подлинности клиента или любого назначения .
По умолчанию — не применимо.
Примечание
Когда включены и Издатель сертификата и Расширенное использование ключа (EKU), только сертификаты, удовлетворяющие обоим условиям, считаются допустимыми сертификатами для проверки подлинности клиента на сервере.
Двухфакторная аутентификация
Опытным системным администраторам и службам безопасности хорошо известно, что пользователи крайне не сознательны в вопросе соблюдения политик безопасности, они могут записать свои учетные данные на стикере и приклеить его рядом с компьютером, передать пароли своим коллегам и тому подобное. Особенно часто это происходит, когда пароль сложный (содержащий более 6 знаков и состоящий из букв разного регистра, цифр и специальных символов) и его трудно запомнить. А ведь такие политики администраторами задаются не просто так. Это необходимо для защиты учетной записи пользователя от простого перебора паролей по словарю. Также администраторы рекомендуют менять пароли хотя бы раз в 6 месяцев, просто из того соображения, что за это время теоретически можно отбрутфорсить даже сложный пароль.
Давайте вспомним, что такое аутентификация. В нашем случае это процесс подтверждения подлинности субъекта или объекта. Аутентификация пользователя — это процесс подтверждения подлинности пользователя.
А двухфакторная аутентификация — это такая аутентификация, в которой необходимо использовать не менее двух различных способов для подтверждения своей личности.
Простейшим примером двухфакторной аутентификации в реальной жизни является сейф с замком и кодовой комбинацией. Чтобы открыть такой сейф необходимо знать код и владеть ключом.
Если что-то не работает
Последовательно проверьте, что вы ничего не упустили:
- Установлена свежая версия Microsoft Visual C++ Redistributable;
- С рабочей станции открыт доступ по UDP порту 1812 на адреса вашего RADIUS адаптера или radius.multifactor.ru;
- Операционная система имеет 64 битную разрядность;
- Параметры Nas Identifier и Shared Secret указаны корректно;
- Пользователю настроен хотя бы один второй фактор;
- Проверьте журнал «Запросы доступа» в Личном кабинете Мультифактора;
- Проверьте события в системном журнале Windows от источника MultifactorLogon и LogonUI;
- Доступ без второго фактора доступен при загрузке в безопасном режиме.
